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INTRODUCTION 

Companies seeking to develop microcomputer appli- 
cations are faced with two significant problems. First, 
applications are growing more and more sophisticated. 
With competition always present, products are con- 
tinually being enhanced with new features. This bur- 
dens the underlying computer system by increasing 
both the complexity of the software and the number of 
events and functions that must be handled by the 
system. 

The second problem is a management problem. These 
newer and more sophisticated application systems 
must be developed quickly in order to hit shrinking 
market windows. Also, they must be developed with 
lower manpower costs to be feasible in an engineering 
community struck by insufficient technical personnel 
and sk 5 nocketing software development costs. 

These are the needs addressed by the iRMX 86™ Oper- 
ating System. The two goals in the development of this 
product have been power/flexibility to meet the needs 
of increasingly complex apphcation systems, and ease 
of understanding and use, to boost the productivity of 
available engineering resources. Users of Intel’s hne of 
iSBC 86™ Single Board Computers or custom-designed 
8086-based boards can now obtain the same benefits 
from Intel supplied system software as they can from 
Intel supplied system hardware. 

The reader of this application note is provided with 
information in four subject areas. 

• The requirements of operating systems are 
discussed along with traditional solutions. 

• The iRMX 86 Operating System is introduced 
and its features are discussed in relation to the 
requirements studied earlier. 

• System design using the iRMX 86 Operating 
System is studied using example solutions. 

• Code for two example systems is examined to 
learn the details of system implementation. 

Some of the topics in this note may not be of interest 
to all readers. For example, an experienced real-time 
programmer may not need to read the entire overview 
of real-time systems. For those who want to brush up 
on a few topics, the overview is organized to allow the 
reader to focus attention on areas of specific interest. 

Throughout this application note, various terms and 
concepts are introduced and discussed. If further 
information on any of these topics is desired, the 
references listed in the front of this note should be 
used. 


OVERVIEW 

This overview is provided to investigate both the prob- 
lems encountered in the design of applications soft- 
ware and also the classical solutions to these problems. 

Multitasking 

A real-time system is defined to be a system that 
reacts to events occurring external to the computer 
and which monitors or controls these events as they 
occur (or in “real-time”). The converse of a real-time 
system is known as a batch system where the outcome 
of a program does not depend on when it is run (for 
example, a payroll program). 

Two other characteristics typically encountered in a 
real-time system are asynchronous event occurrences 
and concurrent activity. The first characteristic is 
caused by events occurring randomly rather than at 
scheduled intervals. The second characteristic, con- 
current activity, takes place when two or more events 
occur nearly at the same tim.e, requiring simultaneous 
activity. 

One method of dealing with the requirements of a 
real-time system would be to write a program that 
knows what events could potentially occur (for 
example, an interrupt occurrence, a real-time clock 
counting down to zero, a byte in memory being 
modified by another program). This program could 
then execute a large loop checking for the occurrence 
of these events. 

There are several problems with this approach. While 
processing one event which has occurred, the program 
is not responsive to other events. Also, the 
programmer has no way of prioritizing the importance 
of the various events. From a maintenance standpoint, 
this program is complex and difficult to enhance or 
modify. 

The traditional solution to these problems is a tech- 
nique called multitasking. Essentially, this involves 
writing many small routines instead of one large one. 
Each of these routines (tasks) can process events in- 
dependent of the other tasks in the system. In addi- 
tion, a priority can be assigned each task so that the 
operating system can decide as to which task is the 
most important when more than one task requests 
control of the CPU. 

The support for multitasking involves a scheduler 
which is part of the service provided by the operating 
system. The scheduler allows each task to execute its 
program as if it has sole control of the CPU, ensuring 
that all tasks desiring CPU time are serviced according 
to the priority associated with each task. 


1 


AFN-01540A 



AP-86 


From the standpoint of system design, multitasking 
has many desirable qualities. Large and potentially 
complex application programs can be decomposed into 
smaller more manageable units. This makes feasible 
the use of programmer teams to implement the appli- 
cation. Perhaps even more importantly, the potential- 
ly overwhelming problems surrounding concurrent exe- 
cution and interrupt handling become transparent to 
the application programmer. Also, multitasking 
makes the modification of existing tasks and the 
addition of new ones become a manageable objective 
since the interaction between tasks is minimized. 

Interrupt Handling 

A common event in a real-time system is the occur- 
rence of an interrupt. Because this event is so com- 
mon, an important feature of a real-time operating 
system is its interrupt processing capabilities. 

From the standpoint of application software, interrupt 
handling can be cumbersome. The currently running 
task must be preempted, various hardware devices 
must be manipulated and perhaps a hardware inter- 
rupt controller must be dealt with. 

A re?il-tiiTie onprstino' cvpfprn p.pr> +V>r> nr»r*'?ir 

rence of an interrupt into something more consistent 
with the way other events are handled. A task can 
simply inform the scheduler that it does not require 
any CPU time until an interrupt occurs. The relative 
priority of different interrupts can also be handled in 
the same manner as the priority of multiple tasks are 
handled. Thus, the application programmer need only 
deal with the actual processing related to interrupt 
occurrence. 

Reliability 

Reliabihty is a keyword in all real-time systems. In 
this type of system, reliability does not refer to mean 
time between failure. In fact, the software in a real- 
time application typically cannot be allowed to fail. 
The difficulty imposed on the software by the en- 
vironment comes from the near infinite number of 
permutations that can occur. A system that appears to 
be fully debugged can fail in the field because of a 
combination of simultaneous events that never 
occurred before. 

The only means to avoid failure in these instances is 
through the use of a consistent, well-thought-out 
model for handling events. Any special-cased solution 
is subject to failure when the special cases that were 
designed for are violated in the real world. 

Error handling can also add reliability to an appli- 
cation system. When the application software is 


unable to anticipate the outcome of certain conditions, 
or the software has undiscovered bugs, it is vital for 
the operating system to gracefully handle the situation 
and allow for further processing to continue as best as 
possible. 


I/O Handling 

Many applications for 16-bit microcomputers require a 
variety of I/O devices. The support for I/O opera- 
tions on these devices is typically provided by the 
operating system. Both sequential access and random 
access devices are typically encountered and, in addi- 
tion, flexibility in handling I/O requests and acknowl- 
edgements is important. 

The flexibility necessary typically involves the sched- 
uhng of a task’s execution after an I/O request has been 
made. The greatest flexibility can be obtained by an 
asynchronous I/O system. In this system, a task makes 
an I/O request by calling the operating system. Once 
the processing of the request has begun, control is 
returned to the calling task. 
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program while the I/O operation is progressing. When 
the results of the operation are desired, the task can 
call the operating system again to wait for the com- 
pletion of the previous I/O request. 

The second type of I/O support is less flexible but also 
easier to use. An operating system that supports syn- 
chronous I/O allows a task to make a single operating 
system call to make an I/O request. Once control is 
returned to the calling task, the I/O operation is 
complete and the results are immediately available. 
This type of I/O support sometimes takes advantage of 
a technique known as autobuffering to regain some of 
the performance advantage of the overlapped I/O 
found in the asynchronous system. 

Debug Support 

The inherent characteristics of the real-time environ- 
ment sometimes make it difficult to debug new soft- 
ware. If the simultaneous occurrence of two events 
causes a bug in the software, detection may be difficult 
because the next time the system is run the error is not 
reproduced. Also, because of the fact that the software 
is broken down into many independent tasks, the in- 
teraction may be difficult to track using standard 
debugging techniques. 

The solution to these problems is a piece of software 
called the system debugger. The debugger typically 
has three characteristics. 
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1) It is designed to interact with the operating system 
and therefore has intimate knowledge of code, data 
structures and system objects. 

2) Since the debugger is just another task in the 
system, it does not affect the operation of the other 
tasks that are running. 

3) Through the use of sophisticated breakpointing 
facilities, the debugger allows the designer to track 
the tasks in the system, investigate their interac- 
tion with other tasks and selectively stop one or 
more tasks without stopping the entire system. 


Multiprogramming 

In some apphcation systems, there arises the require- 
ment to run several “applications” on the computer at 
the same time. This may be due to the desire to 
squeeze more use out of the hardware or it may be due 
to some system design consideration. These separate 
“applications” (often termed jobs) share many system 
resources (especially the CPU) but at the same time 
they need to be protected as much as possible from 
other jobs. In essence, it should be possible to develop 
two jobs independently and then run them both on the 
same hardware without any interaction. If interaction 
is desired, the operating system should support some 
well-defined protocol for jobs to use to communicate. 

Free Space Management 

One of the most important resources in the computer 
system is the memory. In some apphcations, the 
amount of memory needed can be determined when 
the system is designed. In the more general case, the 
amount of memory needed by the system fluctuates. 
One solution to this management problem is to have 
available the amount needed in the worst possible 
case. A more flexible and economical solution is to 
dynamically allocate memory from a central pool upon 
demand and return it when possible. This service 
provides two tangible advantages. First, total memory 
needs are reduced. Second, this service allows for ease 
of use by the application programmer because there is 
no need to set aside blocks of memory and implement 
code to maintain information about current usage. 

File Management 

The ability to easily store and retrieve data stored on 
mass storage devices is a requirement in many appli- 
cation systems. Devices such as disks, tapes and bubble 
memories are used to store program code, data files 
and parameter tables. The operating system is called 
upon to store and retrieve the data and organize it 
such that application programs can easily find and 
manipulate the data when necessary. 


Typically, this service is provided through the use of a 
file system. The mass storage device is partitioned into 
blocks and logical addresses are assigned to the blocks. 
Files are created to serve as directories where the 
names of other files can be cataloged and looked up. 

In many systems, the directory structure can go many 
levels deep (see Figure 1). This provides several advan- 
tages. Directory searches can be done much faster if 
the general area where a file exists is known. Also, if 
several jobs are running at the same time, each can be 
given its own directory and therefore isolated from the 
others. Lastly, for human users, it is much easier to 
manage the information on the disk when some logical 
structure of files exists. 



Figure 1. Hierarchical File System 
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Device Independence 

One of the unfortunate characteristics of I/O devices is 
that they all tend to present different interfaces to the 
system software. When this is the case, the application 
programmer must become familiar with the unique 
characteristics of each device in order to communicate 
with it. One solution is to create an I/O driver which 
does the actual I/O. This driver can then be called by 
the application program whenever communication 
with the device is desired. 

The problem with this solution is that the programmer 
must still know what type of device is being talked to 
since the I/O driver is specialized. If the system con- 
figuration changes, all of the software must be 
rewritten to call new device drivers. The best solution 
is to design a standard interface to device drivers and 
postpone until run-time the decision about which 
devices to use. With this type of system, an application 
program can be written assuming that at run-time the 
human or program that invokes it will provide a speci- 
fication of which devices should be used. 

High-Level Man-Machine Interface 

In addition to the services nrovided for anoliratinn 
programs by the operating system, a set of services 
typically is offered to the human user sitting at the 
system console. System utilities are needed for file 
copying, disk formatting, and directory maintenance. 
Programs need to be loaded off disk to run and the 
programs themselves must be able to retrieve 
parameters passed to them by the operator. All of 
these functions are usually provided by the man- 
machine interface software in the operating system. 

Make Versus Buy 

The previous sections dealt with operating system re- 
quirements. These requirements are encountered in 
the application development process. Whether the 
solution to meet the needs comes from the individual 
application designer or from a computer system 
vendor, the requirements do not change. 

There usually exists a rather simple tradeoff between 
designing a custom operating system or buying a 
generahzed system and tailoring it to the individual 
needs of the application. There are advantages to the 
custom solution. The system can often be made 
smaller since the requirements are known in great 
detail. Also, some small performance improvements 
can sometimes be made by taking advantage of the 
special cases to speed things up. 

Buying an operating system from a computer system 
vendor offers five advantages. 


1) Engineering resources are becoming scarce. The use 
of an opearting system from a vendor allows atten- 
tion to be focused on the application software. 

2) The time taken to bring the product to market can 
be shortened, thereby gaining a competitive edge 
and generating early revenue. 

3) Long-term maintenance costs can be reduced be- 
cause the vendor supports the operating system 
software. 

4) Personnel in all branches of the company can be- 
come familiar with one software architecture and 
apply this knowledge to a range of products. 
This apphes not only to the design engineers, but 
also to quality assurance, customer engineers and 
system analysts. 

5) The computer system vendor has knowledge of 
future technological advances coming in the prod- 
uct lines. For this reason, the operating system can 
be constructed so that applications software can be 
transported to future hardware without the need 
for expensive redesign. 

In summary, the trade-offs are clear. An operating 
system from a computer system vendor is not the 
answer for every application. But in most cases, the 
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the expertise of the vendor for the system software 
and use engineering resources to more quickly solve 
the apphcation problem. 

INTRODUCTION TO THE IRMX 86^“ 
OPERATING SYSTEM 

The iRMX 86 Operating System meets the needs of 
real-time applications while simultaneously providing 
the full set of services normally found in a general- 
purpose operating system. 

The overall picture of the iRMX 86 Operating System 
is shown in Figure 2. The iRMX 86 Nucleus provides 



Figure 2. Layers of Support in the iRMX 86^” System 
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support for multitasking, multiprogramming, inter- 
task communication, interrupt handling and error 
checking. The Basic I/O System provides support for 
device independent and file format independent 
manipulation of data on I/O devices. The Extended I/O 
system provides synchronous I/O calls, automatic 
buffering, logical file name support and high-level job 
management. The application loader provides the 
ability to load code and data from mass storage devices 
into RAM memory. The Human Interface provides for 
a high-level man-machine interface as well as file 
utilities and parsing support for application programs. 

The following sections deal in more detail with each of 
these iRMX 86 pieces. If more information is desired on 
the features discussed, please refer to the documents 
Hsted in the front of this application note. 

Architecture 

The iRMX 86 architecture is an object-oriented archi- 
tecture. This means that the operating system is 
organized as a collection of building blocks that are 
manipulated by operators. The building blocks of the 
iRMX 86 system are called objects and are of several 
types. Some of the object types are tasks, jobs, mail- 
boxes, semaphores and segments. These types are 
explained in subsequent sections of this application 
note. 

This type of architecture has two major advantages. 
First, the system is easier to learn and use. The at- 
tributes of the various objects and the operations that 
can be performed on them are well defined and con- 
sistent. Once an object type is understood, all objects 
of that type are understood. 

The second advantage to an object-oriented archi- 
tecture is the ease with which the operating system 
can be tailored to the application. If there is no need 
for a given object in the application, all operators for 
that object are not included in the final configured 
system. On the other hand, if the application designer 
needs a more complex building block that is not in the 
basic system, he can define and use a new object type. 

Table 1 hsts all of the system calls in the iRMX 86 
Nucleus. There are three groupings of system calls in 
this table. 

1) The general system calls apply to ail objects uni- 
formly. 

2) The first two system calls for each object are the 
create and delete calls. These calls simply create a 
new object and initialize its attributes or delete an 
existing object. 


3) The remaining system calls are specific to the at- 
tributes of a particular object. With this organiza- 
tion in mind, the entire operation of the iRMX 86 
nucleus can be glimpsed in a single table. 

Tasks 

Tasks are the active objects in the iRMX 86 archi- 
tecture. Tasks execute program code and therefore are 
the only objects that can manipulate other objects. The 
attributes of a task include its program counter, stack, 
priority and dispatcher state. 

Tasks compete with each other for CPU time and the 
iRMX 86 scheduler determines which task to run based 
upon priorities. The dispatcher states for an iRMX 86 
task are shown in Figure 3. At any given point in time, 
the highest priority task that is ready to run has 
control of the CPU. Control is transferred to another 
task only when 



Figure 3. T ask State T ransition Diagram 


1) the running task makes a request that cannot im- 
mediately be filled and is, therefore, moved to the 
asleep state, 

2) an interrupt occurs causing a higher-priority task to 
become ready to run or 

3) the running task causes a higher-priority asleep 
task to become ready by releasing some resource. 

The suspended and asleep-suspended states are 
entered whenever the suspend system call is invoked 
for a particular task. 

Job and Free Space Management 

Support for multiprogramming is provided by the job 
object. A job provides the environment for tasks to 
execute their programs. All other objects needed for a 
particular application are contained within the job. 
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Table 1. Nucleus Object Management System Calls 


System Calls for 
All Objects 

O.S. Objects 

Attributes 

Object-Specific 
System Calls 

CATALOG$OBJECT 

UNCATALOG$OBJECT 

LOOKUP$OBJECT 

ENABLESDELETION 

DISABLE$DELETION 

FORCE$DELETE 

GFTS;typf 

JOBS 

Tasks 

Memory pool 
Object directory 
Exception handler 

CREATESJOB 

DELETE$JOB 

SET$POOL$MIN 

GET$POOL$ATTRIB 

OFFSPRING 

TASKS 

Priority 

Stack 

Code 

State 

Exception handler 

CREATESTASK 

DELETE$TASK 

SUSPEND$TASK 

RESUMESTASK 

GET$EXCEPTION$HANDLER 

SET$EXCEPTION$HANDLER 

SLEEP 

GET$TASK$TOKENS 

GET$PRIORITY 

SET$PRIORITY 

SEGMENTS 

Buffer with length 

CREATE$SEGMENT 

DELETESSEGMENT 

GET$SIZE 

MAILBOXES 

List of objects 

List of tasks waiting for objects 

CREATESMAILBOX 

DELETE$MAILBOX 

SENDSMESSAGE 

RECEIVE$MESSAGE 

SEMAPHORES 

Semaphore unit value 
List of tasks waiting for units 

CREATE$SEMAPHORE 

ucLC i ccfrcaciviMmutic. 

RECEIVE$UNITS 

SEND$UNITS 

REGIONS 

List of tasks waiting for critical 
section 

CREATESREGION 

DELETE$REGION 

RECEIVE$CONTROL 

ACCEPTSCONTROL 

SENDSCONTROL 

USER 

OBJECTS 

License rights to a given extension 
type 

CREATESEXTENSION 

DELETE$EXTENSION 

New object template 

CREATESCOMPOSITE 

DELETE$COMPOSITE 

INSPECT$COMPOSITE 

ALTERSCOMPOSITE 


A specific attribute of the job is a free memory pool 
from which blocks can be allocated only by tasks 
within the job. Also, the job contains an object direc- 
tory which can be used by tasks to catalog objects 
under ASCII names so that other tasks, knowing the 
ASCII name, can look up the object and thereby gain 
addressability to it. 

More than one job can co-exist in the computer system. 
Tasks within jobs can also create children jobs forming 
a hierarchical tree of jobs (see Figure 4). Each job in 
the system has its unique set of contained objects, its 
own memory pool and its own object directory. 

Segments 

A fundamental resource that tasks need is memory. 
Memory is allocated to tasks in the form of the 



segment object. The segment is a block of contiguous 
memory. The attributes of a segment are its base 
address and size. A task needing memory requests a 
segment of whatever size it requires. The Nucleus 
attempts to create a segment from the memory pool 
given to the task’s job when the job was created. 
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If there is not enough memory available, the Nucleus 
will try to get the needed memory from ancestors of 
the job. 

Communication and Synchronization 

In many cases it is necessary for two tasks to com- 
municate in order to exchange data and commands. 
This is supported through the use of an object known 
as a mailbox. As its name implies, a mailbox is a 
holding place for objects. One task can send an object 
to a mailbox, causing the object to be queued there. 
Another task can later receive an object from the mail- 
box and thereby gain access to it (see Figure 5). If a 
task tries to receive an object from a mailbox and there 
are no objects there, the task can optionally be made to 
sleep for a specified time for an object to appear. 



Figure 5. Intertask Communication via Mailboxes 

Note that any object can be sent to a mailbox to be 
received by another task. Typically, the object sent is a 
segment which is a block of memory and can contain 
any commands or data. The term message is often used 
to describe the object during the time it is being sent 
through a mailbox. 

In those cases where there is a requirement for syn- 
chronization between tasks but no data need be sent, a 
simpler more efficient mechanism exists. The sem- 
aphore object provides for the allocation of abstract 
entities called units. The primary attribute of the 
semaphore is an integer number. Tasks may send units 
to a semaphore thereby increasing the integer number 
or they can request units, thereby decreasing the 
number. If a task makes a request for more units than 
are available, it can optionally be made to sleep for a 
specified amount of time. This mechanism can be used 
for S3mchronization, resource allocation and mutual 
exclusion. 


Interrupt Management 

When an interrupt is sensed by the 8086 hardware, a 
user interrupt handler is executed. The interrupt 
handler can either perform all interrupt processing 
itself without making any iRMX 86 system calls, or it 
can signal an interrupt task allowing more general 
interrupt processing including calls to the operating 
system. 

The operating system maps hardware interrupt priori- 
ties into the software priority scheme allowing the 
designer to specify what software functions are im- 
portant enough to have some interrupt levels masked 
off during their execution. Although this mapping 
should always be kept in mind during design, the 
mechanics of dealing with interrupt control are 
handled by the operating system. 

Error Management 

One of the central themes in the design of the iRMX 
86 operating system has been reliability. The results of 
these efforts are evident in two particular features of 
the architecture. Beyond the ease of understanding 
brought about by the symmetry of the system, the 
reliability of applications using the iRMX 86 software 
is increased. 

The general case (as opposed to checking only for 
specific combinations of errors) has been designed for. 
Because of this, an unexpected combination of events 
or the simultaneous occurrence of interrupts will 
never catch the system by surprise. 

In the event that errors do occur, the operating system 
is set to detect them. Virtually all parameters in calls 
to the operating system are checked for validity. Any 
inconsistency causes a jump to an error routine to 
handle the problem. Two types of errors can poten- 
tially occur and there are two ways of handling errors. 

The first error type is the programmer error condition 
which comes about due to some mistake in the coding 
of a system call. The second type is an environmental 
condition which arises due to factors out of the control 
of the engineer (e.g. insufficient memory). Each of 
these error types can be handled in-line by checking a 
status code upon return from the call or can cause an 
error handling subroutine to be called by the system. 
The system designer can choose the desired method for 
the system, for a specific job, and even for individual 
tasks within a job. 

Asynchronous I/O 

Asynchronous I/O system calls are provided to 
support device independent I/O to any device in the 
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system. The type of I/O and the type of device are 
interrelated as shown in Figure 6. Every device driver 
in the I/O system is required to support a standard 
interface. In this manner, all devices look the same to 
higher level software. In the same manner, the 
individual file drivers, which provide the different 
types of file systems, all have a standard interface and 
call upon the various device drivers to perform I/O. 
These interface standards 

1) provide for the device independence in the higher 
layers of the I/O system 

2) make it easier for Intel to add future device drivers 
as new devices become available and 

3) make it possible for iRMX 86 users to add their own 
drivers for custom I/O devices. 



Figure 6. I/O System Structure 

The iRMX 86 I/O system provides both asynchronous 
and synchronous system calls. The asynchronous I/O 
calls are faster, provide more flexibility in the 
selection of options and allow the program making the 
call to perform other functions while waiting for the 
I/O operation to complete. 

The method by which the I/O system responds to the 
requestor is through the use of a mailbox. When any 
call is made to the asynchronous I/O system, one of the 
parameters indicates a mailbox where the caller 
expects to receive a segment containing the results of 
the operation (see Figure 7). 

Synchronous I/O 

The alternative to using the asynchronous I/O system 
is to use synchronous I/O system calls. As shown in 
Figure 8, the number of options available are fewer 
and the caller cannot continue execution until the 
entire I/O operation is completed but from an ease-of- 
use standpoint, the situation is much simplified. 


Response$mailbox$token = RQ$create$ 
mailbox (0, ©status); 

CALL RQ$A$read(connection$token, buf$ptr, 
count, response$mailbox$token, ©status); 

IORS$token = RQ$receive$message 
(response$mailbox$token,OFFFFH, 
©resp$t, ©status); 

{check status^ 

Call RQ$delete$segment(IORS$token, 
©status); 


Figure 7. Asynchronous I/O Call 


Call RQ$S$read(connectlon$token,buf$ptr, 
count, ©status); 

{check status} 


Figure 8. Synchronous I/O Call 

Two other features provided by the Extended I/O 
System are logical name support and autobuffering. 
Logical names allow the application designer to post- 
pone the decision concerning which files to use until 

rnin.fimo TTcconfion-ir oil r.o-n V>/> J 

compiled using logical file names and then these 
logical names can be mapped into real file names at 
run-time. 

The use of autobuffering regains much of performance 
advantage offered by overlapped I/O. When a user task 
opens a file for input, one or more buffers are auto- 
matically created and filled with data from the file. 
Thus, when the user task makes an I/O request, the 
data may already be available in memory. A similar 
case exists for write requests in that the I/O system 
will buffer data to be written to a device, allowing the 
user task to continue on. 

Loaders 

The iRMX 86 application loader and bootstrap loader 
perform a variety of services for the user software. 
The following is a brief summary of the available 
features. 

1) Systems can be boot loaded from mass storage 
devices at system reset. This saves not only ROM or 
EPROM memory, but also reduces field mainte- 
nance costs by allowing easy field updates. 

2) Users can design their own SYSGEN procedure 
allowing tailoring of an application system to the 
individual installation. 

3) Infrequently used programs can be brought in from 
mass storage when needed instead of using system 
memory unnecessarily. 
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File Management 

There are three types of files supported by the iRMX 
86 I/O system, named files, physical files and stream 
files. Named files are supported on devices possessing 
mass storage capabihty. Files in this system have 
ASCII pathnames and are cataloged in directories. 
Each device in the system contains a directory tree as 
shown previously in Figure 1. Access protection is 
provided through the use of access lists for each file. 
Each user or group of users in the system can be given 
different types of access to the file or can be denied 
access to it. 

For devices that cannot support a named file structure 
(e.g. printers and terminals) the physical file driver is 
used. Devices in this category are treated strictly as 
data going into and/or out of the device. If it is 
desirable to treat a mass storage device strictly as a 
large mass of data, it can also be addressed through 
the physical file driver. 

The third type of file is the stream file. This file type 
has no correlation with any physical device but rather 
uses system memory for temporary storage of data. An 
example of the usage of a stream file is a job that gets 
its input stream of data from a file. Depending on 
which time the job is run, this file might be a named 
file on disk, a terminal, or a stream file being written 
to by another job (see Figure 9). 



Human Interface Subsystem 

The highest level of support provided by the iRMX 86 
Operating System is the Human Interface Subsystem. 
This piece of software provides two basic services. 
Programs can be invoked by typing the program name 
at the system console. The Human Interface will load 
the given program into memory, set it up as a job and 
start it running. The invoked program can then call 
upon the Human Interface routines to determine what 
parameters were passed to it as part of the operator 
input. 
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The Human Interface also contains a set of system 
utility routines which are used to copy files and disks, 
format disks, dynamically alter the system configura- 
tion and others. 

Debugging Subsystem 

The iRMX 86 Debugging Subsystem allows the de- 
signer to interact with the protot 5 rpe system and iso- 
late and correct program errors. Since the debugger is 
an object-oriented debugger and is aware of the in- 
ternal structure of the operating system, it can provide 
detailed information concerning objects and can mon- 
itor mailboxes and semaphores providing a breakpoint 
facility as well as error detection. 

Specifically, the iRMX 86 Debugging Subsystem 
provides six sets of functions: 

1) Wake-up upon operator invocation. The operator 
types a control-D key to cause the debugger to 
wake up. 

2) View system lists. The debugger can viev/ lists of 
objects either globally or specifically for a given 
job. Also, hsts of objects and tasks queued at mail- 
boxes and semaphores can be seen. 

3) Inspect objects. A detailed report on any object can 
be requested showing the current state of all 
relevant attributes. 

4) Inspect and modify memory. 

5) Breakpoint control. Any number of breakpoints 
can be set causing a single task to break on either 
execution of particular instructions or sends and 
receives of messages or units. 

6) Error handhng. The debugger can be set up to be 
the system default error handler thus catching 
system exceptions. 

Configuration and Initialization 

Once the apphcation is designed and coded, the 
engineer needs a mechanism to inform the operating 
system of the software and hardware configuration. 
Essentially, this involves building tables of informa- 
tion using tools provided with the iRMX 86 product. 

As shown earlier in Figure 4, the jobs in an iRMX 86 
system form a hierarchical tree. The root in every job 
tree is known as the root job and is supplied as part of 
the iRMX 86 system. There are three important fea- 
tures of this job. 

1) The root job has an object directory for cataloging 
and looking up objects. The special feature of this 
directory is that is is accessible by all tasks in the 
system since everyone can address the root job. For 
this reason the root object directory is useful for 
setting up inter-job communication paths. 
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2) The root job initially contains all free space in the 
system. Part of the system initialization code per- 
forms a memory scan to automatically determine 
the amount of free RAM in the system. This 
memory is put into the free space pool of the root 
job and parceled out as user jobs are created. 

3) The root job contains only one task, the root task. 
This task scans the configuration tables generated 
by the user and creates the user-specified jobs. 

Examples of configuration, initialization and the 
LINK 86 and LOG 86 operations needed to generate a 
system will be presented in the Code Examples section. 

DESIGN METHODOLOGY 

This section describes the design process involved in 
using the iRMX 86 system to solve application prob- 
lems and presents two example solutions. 

System design with the iRMX 86 Operating System 
should be viewed as a process starting with the highest 
level definition of system requirements and succes- 
sively adding more detail until the end product is 
program code. This description sounds very much like 
the description of top-down design and, of course, it 
siiouiu. ims meuiocioiogy oners not omy qmcKer 
designs, fewer design flaws and easier implementation, 
but also easier maintenance and enhancement. 

In general, every iRMX 86 design progresses through 
the following steps: 

1) Define system requirements. 

2) Breakdown into highest level sub-functions (jobs). 

3) Define job functions. 

4) Determine inter-job command and data flow. 

5) Break down each job into sub-functions. 

6) Based upon requirements, assign tasks to perform 
job functions. 

7) Determine inter-task command and data flow. 

8) Write program code for each task. 

Step 8 becomes the design process associated with the 
application programs themselves. The code for each 
task is essentially a sequential program that performs 
one of the functions of the computer system. Standard 
techniques for top-down design can therefore be used 
here to specify each module and its inputs and outputs 
as well as global and local data structures etc. The end 
product of this procedure is a modularized application 
system that should be easy to debug. 

APPLICATION EXAMPLE 1 

The first example presented here is based on the dis- 
tributed local network diagrammed in Figure 10. Each 
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Figure 10. Block Diagram of Example System 1 


workstation shown is an intelligent terminal having 
local data and program storage. The stations all use 
the File Sharing Node (FSN) for storage and retrieval 
of records in much the same way as the secretaries in 
an office would make use of a filing cabinet. The FSN 
maintains the files on a fixed disk device and responds 
to requests from the workstations for access to the 
data. The design to follow concentrates on the File 
Sharing Node. 

System Requirements 

Each intelligent terminal in the network has command 
processing software. When a file reference is made 
that cannot be satisfied by the local file system, a 
request is made to the File Sharing Node. This request 
consists of a log-on request followed by a string of I/O 
requests and ultimately a log-off request. 

The number of intelligent terminals (workstations) 
hooked up to the FSN varies from installation to 
installation. Therefore, the FSN must be capable of 
handling many simultaneous requests and no assump- 
tions can be made about the maximum number of 
workstations or requests that may need to be handled. 

Each node in the network has a unique address. A 
packet is sent onto the network by one node and the 
address field is examined by all other nodes. If this 
field does not match the node’s address the packet is 
ignored. If a match is found the packet is retrieved 
from the network. 


Hardware Requirements 

The three main hardware building blocks needed by 
this application are shown in Figure 11. The iSBC 
86/1 2 A Single Board Computer will communicate 
with the iSBC 544 Intelligent Communications Con- 
troller to establish and maintain communications with 
the network. The Intel 8085A on the iSBC 544 board 
will perform all of the address recognition, acknowl- 
edgements, packet retrieval and packet transmittal. 
The iSBC 206 Hard Disk Controller will be used to 
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create, maintain and access the data files which are at 
the heart of this application. 



0 



Figure 11. Hardware Block Diagram 
System Design 

The first step in the system design process is the 
breakdown of the system functions into one or several 
jobs. The reasons for doing this are system modularity 
and protection. With this type of design, each job can 
be designed separately, perhaps even by a different 
engineer or engineering team. The input and output 
requirements will be specified very tightly and the job 
will take on the appearance of a black box to other jobs 
in the system. If the job is enhanced or modified at a 
later date, the rest of the system can be left undis- 
turbed providing that the input and output response 
remains the same. 

The job object in the iRMX 86 operating system also 
affords a degree of software protection for the tasks 
and other objects contained within the job. Each job 
has a separate memory pool, a separate object 
directory and a separate identification to the I/O 
system. 

The two primary groupings of functions in this appli- 
cation are those related to the network communica- 
tions and those related to processing the file trans- 
action request. A list of a possible split-up of system 
functions is shown in Figure 12. 


COMMUNiCATiONS JOB 

FILE TRANSACTION JOB 

• iSBC 544’“ INPUT INTERRUPT 
SERVICE 

• RETRIEVE INPUT REQUEST 
PACKETS FOR SERVICING 

• iSBC 544’“ OUTPUT INTERRUPT 
SERVICE 

• DETERMINE WORKSTATION 
STATUS 

• SERVICE OUTPUT REQUEST 
MAILBOX 

• SERVICE TRANSACTION 
REQUESTS 

• QUEUE PACKETS OF INPUT DATA 
AT INPUT MAILBOX 

• PERFORM LOG-ON AND LOG OFF 
FUNCTIONS 

•ACKNOWLEDGEMENT 

GENERATION 

• BUILD AND SEND RESPONSE 
MESSAGES 


Figure 12. Function Split-up 


The communication between the file transaction job 
and the communication job must fulfill two basic 
needs. The communication job will receive interrupts 
when packets addressed to the FSN are received. 
In order to remain attentive to new requests coming 
in, the communications job should have the capability 
to “spool” the requests off to the file transaction job. 
This buffering can be provided by using the mailbox 
object. Segments can be created to contain the packet 
request data and can then be sent to a mailbox where 
the file transaction job can receive and process them. 

When the file transaction job must send a packet to a 
workstation, the requirement is seen for another 
queue of requests. Since the communications board 
can only put one packet at a time on the network, a 
mailbox should be provided to allow tasks in the file 
transaction job to send output request segments into 
the queue and then continue on (see Figure 13). 


Since tasks in both the file transaction job and the 
communications job must have access to these input 
and output mailboxes, some means must be set up to 
“broadcast” the identifier for these objects. 

In the iRMX 86 system, each object has associated 
with it a 16-bit number called a token. Whenever an 
object is referenced in an operating system call, the 
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token for the object is used. For example, assume that 
a segment must be sent to a mailbox. The segment and 
mailbox each have a token and these tokens are passed 
to the operating system as parameters in the 
send$message system call. 

There are three major ways to get the token for an 
object. The first way is to create an object. Whenever 
the operating system is called to create a new object, 
the value returned from the procedure call is the token 
for the new object. The second way to receive a token 
is through the receive message system call where an 
object is received from the queue at a mailbox where it 
was sent by another task. 

The third major mechanism for the receipt of a token 
is provided by the object directory concept. As men- 
tioned previously, each job in the system has an object 
directory. 

If a task in a job has the token for an object and wishes 
to let other tasks in other jobs have access to the 
object, the task can “catalog” the object in the object 
directory. The catalog$object system call takes the 
token for an object and an ASCII name as parameters 
and creates an entrv in the obippt Hirppfnrv Tf smnfVior 
task knows the ASCII name for an object, it can obtain 
the token by performing a lookup$object call. 

The object directory mechanism will be used in this 
example to allow the communications job to “broad- 
cast” the tokens for the input and output mailboxes. 
The jobs for this application are shown in Figure 14. 



The next step of the design methodology calls for each 
job to be further divided into sub-functions. In this 
application note, only the file transaction job is 
studied. 

In time sequence, the file transaction job will: 


1) Retrieve input requests from the mailbox set up by 
the communication job. 

2) Determine state of specified workstation (for ex- 
ample, is it logged on?). 

3) Perform I/O operation or log-on or log-off. 

4) Build and send response to the workstation. 

Recall from the discussion of system requirements 
that the number of nearly simultaneous requests that 
may be received by the FSN is not known. For this 
reason, some mechanism must be provided to allow 
parallel processing of many requests. This should 
prove feasible since the performance of step 3 will 
involve many delays while waiting for the operating 
system to perform I/O operations. 

One straightforward way to provide for parallel 
processing is to create a task for each workstation that 
logs on. In this manner, each I/O request will be 
handled by a unique task. Through the use of the 
iRMX 86 scheduler, maximum CPU utilization will be 
gained by allowing each task to individually compete 
for CPU time. These “worker” tasks fulfill function 3 
and 4 for the file transaction job. 

T?nnr«tir»r» 1 cinH 9 r'o-n Vio fnlfillorl Vnr q oinrrlo foci/- 'T’Viic' 

task will wait at the input mailbox set up by the 
communications job. When a packet is received that 
requests a log-on operation, the “listener” task will 
create a new “worker” task to handle the request. 
Figure 15 shows a picture of the design. 



File Transaction Job 

The string of transaction requests that follow will 
simply be demultiplexed by the listener task. The 
workstation ID will be searched for and, if found, the 
packet will be sent to the appropriate worker task. If a 
request comes in from a station that is not logged on, 
an error response is sent directly to the communica- 
tions output mailbox for transmittal to the station 
that made the request. 
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If the request packet indicates that a station desires to 
log-off, the listener task will delete all local reference 
to the station and pass the packet along. The listener 
task cannot simply delete the worker since the worker 
may be in the process of servicing a previous I/O 
request. In general, it is never a good idea to arbi- 
trarily delete another task. A better protocol is to pass 
along the message signaling the worker task to delete 
itself when convenient. 

An investigation of the intertask communications 
needs highlights the requirement for passing data 
between tasks. The inteijob communications protocol 
discussed earlier specified that the listener task will 
receive input request segments from the communica- 
tions job via a mailbox. 

Within these segments are fields containing the work- 
station ID and the command. Based upon these fields 
one of two things happens. If the command indicates 
that the station wishes to log on, a new worker task 
must be created to process the I/O requests that wiU 
follow. 


listener task or one of the worker tasks needs to 
transmit a packet to a workstation, a segment is sent 
to the output request mailbox of the communication 
job. 

The final step in the design methodology is to write 
program code for the tasks in the system. This step is 
performed in the Code Examples section. 

APPLICATION EXAMPLE 2 

This example will deal with the design of a custom 
device driver for the iRMX 86 operating system. As 
shown in Figure 6, a device driver accepts high-level 
commands from the file drivers (such as read, write, 
seek, etc.) and transforms these commands into I/O 
port read and write commands in order to commu- 
nicate with the device itself. By studying the construc- 
tion of a driver for the iSBC 534 Serial Communication 
Expansion Board, a better understanding of the iRMX 
86 I/O system will be gained along with an example of 
the use of nucleus facilities to construct a higher-level 
software function. 


The code executed by all worker tasks will be identical 
since they all perform identical functions. However, 
some unique pieces of information must be passed to a 
new worker task. This can be accomplished by having 
the worker task first wait at a “log on” mailbox. Here it 
will receive a segment from the listener task which 
contains the necessary information (see Figure 16). 



Figure 16. Communications Between Listener 
Task and a Newiy Created Worker Task 


After this initialization is complete, the workstation 
requests that are received by the listener task can be 
sent to the service mailbox associated with the work- 
station. The token for the service mailbox is one of the 
pieces of information contained in the log on segment. 

The last communication path needed is predefined by 
the interjob communication protocol. When either the 


Overview of Device Driver Construction 

Each I/O device consists of a controller and one or 
more units. A device as a whole is identified by a 
device number. Units are identified by unit number 
and device-unit number. The unit number identifies 
the unit within the device and the device-unit number 
identifies the unit among all the units on all of the 
devices. 

A device driver must be provided for every device in 
the hardware configuration. That device driver must 
handle the I/O requests for all of the units on the 
device. Different devices can use different device 
drivers; or if they are the same kind of device, they can 
use the same device driver code. 

At its highest level, a device driver consists of four 
procedures which are called directly by the I/O 
System. These procedures can be identified according 
to purpose, as follows: 

Initialize I/O 
Finish I/O 
Queue I/O 
Cancel I/O 

When a user makes an I/O System call to manipulate a 
device, the I/O System ultimately calls one or more of 
these procedures, which operate in conjunction with 
an interrupt handler to coordinate the actual I/O 
transfers. This section provides a general description 
of each of these procedures, and the interrupt handler. 
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INITIALIZE I/O 

This procedure creates all of the iRMX 86 objects 
needed by the remainder of the routines in the device 
driver. It typically creates an interrupt task and a seg- 
ment to store data local to the device. It also performs 
device initialization, if any such is necessary. The I/O 
System calls this routine just prior to the first attach 
of a unit on the device (the first RQ$A$PHYSICAL 
$ATTACH$DEVICE system call). The time sequence 
of calls to these procedures will be described a little 
later. 

FINISH I/O 

The I/O System calls this procedure after all units of 
the device have been detached (the last RQ$A$ 
PHYSICAL$DETACH$DEVICE system call). The 
finish$IO procedure performs any necessary final 
processing on the device and deletes all of the objects 
used by the device handler, including the interrupt 
task and the device-local data segment. 

QUEUE I/O 

This procedure places I/O requests on a queue, so that 
they can start when the appropriate unit becomes 
available. If the device is not busy, the queue$IO 
piuceuuie otai U3 uie request. 

CANCEL I/O 

This procedure cancels a previously queued I/O 
request. Unless the device is such that a request can 
take an indefinite amount of time to process (such as 
keyboard input from a terminal), this procedure can 
perform a null operation. 

INTERRUPT HANDLERS AND INTERRUPT TASKS 

After a device finishes processing an I/O request, it 
sends an interrupt to the iRMX 86 system. As a 
consequence, the interrupt handler for the device is 
called. This handler either processes the interrupt 
itself or signals an interrupt task to process the 
interrupt. Since an interrupt handler is limited in the 
types of system calls that it can make, an interrupt 
task usually services the interrupt. The interrupt task 
feeds the results of the interrupt back to the appli- 
cation software (data from a read operation, status 
from other types of operations). It then gets the next 
I/O request from the queue and starts the device 
processing this request. This cycle continues until the 
device is detached. The interrupt task is normally 
created by the initialize I/O procedure. 

The I/O System calls each one of the four device driver 
procedures in response to specific conditions. Three of 
the procedures are called under the following 
conditions. 


1) In order to start I/O processing, the user must make 
an I/O request. This can be done by making a variety 
of system calls. However, the first I/O request to 
each device-unit must be the RQ$A$PHYSICAL$ 
ATTACH$DEVICE system call. 

2) The I/O System checks to see if the I/O request 
results from the first RQ$A$PHYSICAL$ATTACH 
$DEVICE system call for the device (the first unit 
attached in a device). If it is, the I/O System realizes 
that the device has not been initialized and calls the 
initialize I/O procedure first, before queueing the 
request. 

3) Whether or not the I/O System called the initialize 
I/O procedure, it calls the queue I/O procedure to 
queue the request for execution. 

4) The I/O System checks to see if the request just 
queued resulted from the last RQ$A$PHYSICAL$ 
DETACH$DEVICE system call for the device (de- 
taching the last unit of a device). If so, the I/O 
System calls the finish I/O procedure to do any 
final processing on the device and clean up objects 
used by the device driver routines. 


The I/O System calls the fourth device driver 

W'Aavj ocaaaoOx LiiiULtC/i. 

following conditions: 

• If the user makes an RQ$A$PHYSICAL$ 
DETACH$DEVICE system call specifying the 
hard detach option, in order to forcibly detach 
the connection objects associated with a device- 
unit. 

• If a job containing the task which made the 
request is deleted. 

Each procedure will now be discussed in more detail. 
The initialize $10 procedure takes three parameters: 

init$io: Procedure (duib$p, ret$data$t$p, status $p) 

The duih$p parameter contains a pointer to a device 
unit information block (DUIB) which is the configu- 
ration table for the device in question. The structure of 
this table is shown in Figure 17. Note that this table 
contains pointers to device and unit information tables 
which can contain hardware specific information (such 
as I/O base addresses, interrupt levels etc.). 

The second parameter is a pointer to a word which can 
be assigned the value of a token for an iRMX 86 object. 
Quite often this object would be a segment which could 
be created by the init$io procedure and filled with 
information needed by the other procedures in the 
driver. The token for this segment will be provided to 
the other procedures when they are called. 


14 


AFN-01540A 



AP-86 


NAME 

(14) 



Fll F DRIVFRS 


FUNCTIONS 

DEVICE 

GRANULARITY 

DEVICE SIZE 

DEVICE 


UNIT 



DEVICE UNIT 


INITSIO 

QUEUESIO 

CANCELSIO 

FINISHSIO 

DEVICE INFORMATION 
POINTER 

UNIT INFORMATION POINTER 


Figure 17. DUIB Format 

The final argument in the call is a pointer to a status 
word. This word should be assigned by the init$io 
procedure before a RETURN is executed. If a non-zero 
value is returned indicating an error condition, the I/O 
System assumes that init$io has deleted any objects 
created before the error was encountered. 

The finish$io procedure is called by the I/O System just 
after the last detach$device call is made on the device. 
This procedure is expected to delete any objects 
created by the init$io procedure and shut down the 
connected device. 

finish$io: Procedure (duib$p, ret$data$t); 

Once again, the first parameter to the call is a pointer 
to a DUIB. The second parameter is the token returned 
by the init$io procedure. 

The queue$io procedure is called to initiate an I/O 
request. 

queue$io: Procedure (IORS$t,duib$p, ret$data$t) 

The specifics of the request are indicated in an I/O 
request segment (lORS) which is provided by the first 
parameter. The format of this segment is shown in 
Figure 18. The most important fields here are the 
count, function, status and buffer pointer fields which 
tell the queue$io procedure what needs to be done. The 
second and third parameters are once again the 
pointer to the DUIB and the token for the object 


STATUS 



Figure 18. I/O Request Segment Format 

created by the init$io procedure. 

The final device driver procedure is cancel$io. This 
procedure is called by the I/O System to cancel a 
previous I/O request. If the device is of such a nature 
that a request will complete in a bounded amount of 
time, this procedure can be a null procedure. The 
parameters to the call are identical to those for the 
queue$io call. 

In addition to the elementary support discussed here, 
the I/O System provides extra support to the designer 
of a device driver if some simplifying assumptions 
about the device can be made. Also, if the device 
supports random access (such as disks, magnetic 
bubbles, etc.), support routines can be used to simplify 
the process of blocking and deblocking I/O requests. 
More detail on the process of writing I/O drivers can be 
found in the manual titled “A Guide to Writing Device 
Drivers for the iRMX 86 I/O System.” 

Design of an iSBC 534™ Device Driver 

The following section will discuss an example device 
driver for the iRMX 86 Operating System. The driver 
will be for the iSBC 534 board which contains four 
8251 US ART devices; therefore, there is one device 
and four units on the device. 

The init$io procedure for this driver initializes the 
hardware, creates an interrupt task, creates other 
necessary objects and creates a segment to contain the 
relevant information. 
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The structure of the queue$io procedure is more 
complex. When calls are made to this procedure to per- 
form data reading and writing, the actual operation 
could be somewhat lengthy (especially an input 
operation). Since the queue$io procedure is called by 
the I/O system, it is not efficient to perform the entire 
operation before control is returned to the I/O system. 

A more efficient mechanism is to have an independent 
task take the request and fulfill it while the queue$io 
procedure returns to the I/O system allowing other 
operations to be started in parallel. This leads to the 
structure diagrammed in Figure 19. When a read or a 
write request is received, the I/O request segment is 
sent to the request mailbox where it is received by an 
I/O handler task. When the request is complete, the 
I/O task sends the segment to the response mailbox 
indicated in the segment. 



Figure 19. Queue$io Procedure Interface 
to I/O Tasks 


The remaining design of the device driver is concerned 
with interrupt handling. The iSBC 534 board contains 
four 8251 USART devices. Each device supplies two 
interrupts; one indicating that the receiver has a data 
character available and the other indicating that the 
transmitter is ready to accept a character. Each of 
these interrupts (8 in all) are connected to one of the 
8259 Interrupt Controllers on the board. The software 
on the iSBC 86/12A board must read a register in the 
8259 controller to determine which of the eight sources 
caused the current interrupt. This information must 
then be fed to the I/O task which may be waiting for 
the event. 

One way to meet this requirement uses an interrupt 
task for the iSBC 534 board. The task receives the 
interrupt, determines which device caused it, and 
.sends a unit to a semaphore to indicate the occurrence 
of the event. Thus, when an I/O task wishes to be 
informed of a receiver or transmitter interrupt, it 
simply tries to receive a unit from the appropriate 
semaphore. If a unit is available, the receiver has a 
character or the transmitter is ready. If the unit is not 


available, the USART is not ready and the task will be 
put in the asleep state until the interrupt occurs and 
the unit is sent. 

CODE EXAMPLES 

This chaper will present and analyze some sample code 
for the iRMX 86 applications presented in Chapter 4. 
The code listings are contained in Appendix A and the 
individual modules are numbered sequentially. When 
a specific line or sequence of lines of code must be 
pointed out in the text, a two part number is used 
where the first part is the module number and the 
second is the compiler-assigned line number. For 
example, 3.27 would be used to point out line 27 in 
module 3. 

A standard set of suffixes to labels will be followed in 
the code to follow. A PL/M-86 WORD variable that 
will contain the token for an iRMX 86 object will have 
the suffix “$t.” A POINTER variable will be followed 
by and a structure used to overlay a POINTER 
allowing access to the base and offset will be followed 
by “$p$o"’ 

I i<itAner Task 

The first module to be studied contains the code for 
the listener task. The various include statements bring 
in literal declarations and external procedure decla- 
rations. The file NUCPRM.EXT is on the iRMX 86 
diskette and contains the external declarations for all 
iRMX 86 nucleus system calls. 

Line 1.323 contains all of the declarations for the 
module. The literal req$segment$struc is used to 
access the fields of a segment returned from the com- 
munications job. The format of a request packet from 
a workstation is shown in Figure 20. The literal node is 
used to access the information in a segment used as a 
workstation descriptor in a list maintained by the 
listener task. The format of a node in this list is shown 
in Figure 21. The structure at the end of the declara- 
tion statement is used to individually access the two 
halves of a 32-bit PL/M-86 POINTER. 

Note in line 1.330 that the task is coded as a public 
procedure having no parameters. A main procedure 
should never be used for a task’s code since the pre- 
amble for a main procedure sets the stack pointer. 

The mailbox to be used for sending a newly created 
worker task an information segment is called the 
log$on$info$mbox. This mailbox is created in line 
1.331. Lines 1.332-1.334 perform the operation of 
finding the tokens for the communication job’s input 
and output request mailboxes in the object directory of 
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FUNCTION 



Figure 20. Request Packet Format 


LINK FORWARD 
LINK BACKWARD 
WORKSTATION ID 
SERVICE MAILBOX 
WORKER TASK TOKEN 
RESPONSE MAILBOX 


Figure 21. Workstation Descriptor Format 

the root job. The token for the root job is obtained by 
the system call in 1.332. 

Whenever a workstation logs on, various actions are 
taken by the listener task. One of these actions 
involves adding a descriptor for the workstation to a 
hst so that the state of the workstation can be main- 
tained by the hstener task. The list structure is shown 
in Figure 22. Statements 1.336-1.340 create the root 
of this hst and initiahze the hst to an empty state. 

Line 1.340 marks the beginning of an infinite loop. 
Most often a task executes a procedure which performs 
some initialization and then enters an endless loop 
performing the necessary processing. The hteral “for- 
ever” translates into “while 1 .” 

A packet is received from the input mailbox by the call 
in hne 1.341. The command field of the message is 
checked in hne 1.343. If the command indicates that a 
log on request is being made, hnes 1.345-1.356 are 
executed. A log on information segment is created in 
hne 1.345. A mailbox is created to handle further 
request packets and another is created to be used by 
the worker task as a response mailbox. The worker 



Figure 22. Workstation Descriptor List Structure 


task that will handle I/O requests from this work- 
station is created in hne 1.351. Note the use of the 
structure data$seg$p$o, which is declared at the same 
address as the POINTER data$seg$p. The POINTER is 
initialized to equal the beginning of the data segment 
of the worker task module (1.323) and then the base 
portion is used as a parameter in the create task call. 

Once the worker task is created, it will wait at the 
log$on$info$mbox for a segment giving it its initiali- 
zation information. The segment is sent in hne 1.352 
and received back as an acknowledgement inline 1.353. 
At this point, the segment is inserted on the hst of 
active workstation descriptors by the call in hne 1.354. 
Finally the request packet itself is sent to the worker 
task via the service mailbox for the new worker. 

If a log off request is received, hnes 1.358 to 1.366 are 
executed. First, the active workstation list is searched 
for the ID of the requesting station. If the station is 
not found to be logged on, the status field is set and 
the request segment is sent to the workstation through 
the communications job. If the station is logged on, the 
descriptor is deleted from the hst, the packet is sent 
along to the worker task, and the descriptor is deleted. 

If the command is anything but log on or log off, hnes 
1.368-1.376 are executed. Once again the station ID is 
checked to see if it is logged on. If not, an error 
message is returned. If the station is logged on, the 
request packet is sent along to the worker task. 
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WORKER TASK 

The code for the worker task is shown in module 2. 
Upon creation of a new worker task, a segment is 
received at the log$on$info$mbox (2.242). The data in 
this segment is copied into local variables and the 
segment is returned (2.247). 

The initialization task for this job has already created 
a user object for this job and has also set up a prefix 
which points to the root directory for the disk device. 
These tokens have been cataloged in the root object 
directory. The worker task obtains these tokens 
through the sequence of calls 2.248-2.250. 

The worker task now enters an infinite loop servicing 
the workstation it is assigned to. The specific action to 
be taken by the worker is determined by inspecting the 
cmd field of the request message. 

If the command is a log on, the code from 2.256-2.263 
is executed. The file name specified in the request 
segment is attached and opened and thereby made 
ready for subsequent I/O requests. After this, an ac- 
knowledgement is sent back to the workstation via the 
output$request$mailhox (2.263). 

If a log off command is received, the file is closed and 
detached, the service and response mailboxes are 
deleted, a response is sent to the workstation and the 
worker task is deleted. 

If the command is either a read or write command, the 
operation is performed by calling the I/O system. 
When the response is received, an acknowledgement is 
sent to the workstation. Note that the task would 
normally perform more processing. In this example its 
duties have been kept simple. 

POINTERIZE PROCEDURE 

The ASM-86 code for the pointerize support routine is 
shown in Module 3. The token for a segment is the 
base portion of a 32-bit POINTER to the memory. In 
order to access the data in a segment, this 16-bit token 
must be loaded into the base part of a POINTER while 
the offset portion of the POINTER is set to zero. The 
base and offset values are returned in the ES and BX 
regusters as specified by the PL/M-86 calling con- 
ventions. This is the operation performed by the 
pointerize routine. 

LIST MANIPULATION ROUTINES 

Lines 4.1-4.47 provide three subroutines used by the 
tasks in this system to manipulate the list of work- 
station descriptors. Insert$on$list (4.15-4.26) inserts 
the indicated node at the head of the list whose root is 
given as the first parameter. 


Delete$from$list (4.27-4.35) unlinks the indicated 
node from the list it belongs to. Search$list (4.36-4.46) 
searches a list for the workstation ID given. If the ID is 
not found, a zero is returned. If the ID is found, the 
token for that node is returned. 

At this point an overview of the configuration process 
is needed. A more detailed coverage of the process of 
configuring an iRMX 86 system is provided in the 
manual entitled “iRMX 86 Configuration Guide for 
ISIS-II Users.” 

For each iRMX 86 application, the following steps 
must be performed. 


1) Program code for each task in the system must be 
written and compiled or assembled. 

2) A memory map for the software must be drawn up. 

3) The system software must be linked and located. 

4) The application jobs must be linked and located. 

5) Tables of configuration data must be drawn up. 

6) The tabular data from step 5 must be formatted 
into a memory data block through the use of a set 
of ASM-86 macros provided with the iRMX 86 
product. 

7) The root job must be linked and located. 

The code executed by the root task is part of the iRMX 
86 system code. This task is initially the only task in 
the system. The root task will access the data block 
constructed by the ASM-86 macros and will create the 
user jobs specified by the macros. The data for the 
configuration process for example 1 is shown in 
Appendix B, 

The first page diagrams the memory map for the 
example. The iterative link and locate process to put 
these pieces together begins on the second page. The 
LINK86 and LOC86 commands shown place the 
iRMX/86 nucleus into memory. The LOCATE map 
indicates that the last memory location used by the 
nucleus was 077DFH. Therefore, the next contiguous 
piece, the I/O system, is located at 077EOH. 

This process is repeated for the remainder of the jobs 
in the system. 

When the link and locate process is complete, the 
information for the ASM-86 macros must be brought 
together. Worksheets are provided in the iRMX 86 
configuration guide to simplify this process. 

The filled-out worksheets for the macros are shown in 
the appendix. A configuration file is constructed using 
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the editor and the worksheet information is entered 
into this file. When the file is complete, the con- 
figuration table is created by assembling the file 
CTABLE. A86. This file accesses the configuration file 
built earher. 

The configuration tables are then linked and located 
together with the code for the root task and the system 
generation process is complete. 

EXAMPLE 2 

INIT$IOANDFINISH$IO 

The start$and$finish module (5.1-5.371) contains the 
code for the init$534$io and finish$534$io pro- 
cedures. The init$534$io procedure creates a seg- 
ment, shown in Figure 23, which is used to hold the 
various pieces of information needed by the other 
driver procedures (5.323). The discussion of this 
procedure in Chapter 4 pointed out that any errors 
encountered in the initialization are indicated by the 
non-zero status and that the assumption is made that 
any partial creations must be cleaned up by the init$io 
procedure. This assumption is carried out by the check 
at line 5.324 (and the others at 5.331, 5,335, 5.339 and 
5.342). 


INTERRUPT LEVEL 

I/O BASE 
ADDRESS 


INTERRUPT 

PENDING SEMAPHORE (8) 

INTERRUPT TASK TOKEN 

REQUEST MAILBOX TOKEN 

USART COM- 
MAND PORT (4) 


USART DATA 
PORT (4) 

TIMER COM- 
MAND PORT (4) 

TIMER LOAD 
PORT (4) 

TIMER COM- 
MAND (4) 


Figure 23. init$534$io Segment Format 

The device information contained in the device unit 
information block for this device is retrieved in line 
5.328-5.329. A mailbox to be used for sending I/O 
request segments to the I/O handler tasks is created in 
hne 5.330. The interrupt task for this job is created by 
the call in line 5.337. 

The do loop starting at hne 5.340 is executed to create 
eight semaphores to be used by the interrupt task to 
indicate the occurrence of an interrupt. Note that the 
initial value of the semaphore is zero (no interrupt 


pending) and the maximum value is one. Since the 
nature of the 8251 USART device does not support 
buffering, when a new character overruns the previous 
character before the interrupt can be serviced, the 
data is lost. Therefore, there is no need to indicate the 
occurrence of multiple interrupts pending on the same 
device. 

The call at line 5.345 initializes the programmable 
devices on the iSBC 534 board. If execution has 
proceeded to line 5.346, the initialization is complete 
and a zero status is returned. If an error occurred at 
any point, the code in lines 5.348-5.356 will clean up 
the partial initialization. 

"Vhefinish$534$io procedure (5.358-5.370) undoes the 
work of the init$534$io procedure. The segment, 
mailbox, interrupt task and semaphores are all 
deleted. 

The queue$534$io procedure is shown in lines 6.1- 
6.382. In line 6.322 the function field of the I/O 
request segment is checked to see if it is within 
bounds. If it is not, a bad status code is returned. If the 
function is valid, a do case block is executed using the 
function code as the index. 

If a read request is encountered, the auxiliary pointer 
is set to point to the ret$data structure (initialized 
earlier by the init$534$io procedure). In line 6.327 the 
segment is then sent to the request mailbox to be 
received and processed by an I/O processor task. In 
hnes 6.330-6.334 the same action is taken with write 
requests. 

Since this driver does not support seeking and special 
functions, the code for these two cases simply returns 
an error condition. 

In the case of an attach$device call, the code in lines 
6.341-6.361 is executed. First, two I/O processing 
tasks are created. All of these tasks execute identical 
code and each task is capable of servicing a read or a 
write request on any 8251. Two tasks are created for 
each 8251 device so that the peak load can always be 
handled (that is, all receivers and transmitters going 
simultaneously). Lines 6.346-6.357 perform the initi- 
alization of the 8251 USART and the baud rate gen- 
erators for this channel. The calls in line 6.358 and 
6.359 accept an interrupt and a character from the 
semaphore associated with the receiver just initialized. 
This is done to clear off an interrupt generated by the 
8251 whenever it is initialized. 

In the case of a detach$device call, the code in lines 
6.363-6.367 sends the I/O request segment to the 
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request mailbox twice. This is done to signal, two of the 
I/O handler tasks to delete themselves. As discussed 
earlier in the attach$device section, none of the I/O 
handler tasks is any different from any of the others. 
There are two created for each 8251 device which is 
attached. The protocol set up for their deletion is 
shown here. When an I/O handler task receives a 
segment of type “detach$device” it will send the 
segment to the response mailbox and then delete itself. 

The code for the open and close requests is the same. 
Both cases are supported but are NOPs since no 
specific action needs to be taken by the driver. 

Lines 6.379-6.382 contain the code for the cancel$ 
534$io procedure. As discussed earlier, this pro- 
cedure is simply a placeholder and serves no par- 
ticular purpose. 

INTERRUPT CONTROL MODULE 

The interrupt handler and interrupt task are shown in 
hnes 7.1-7.329. The interrupt task is the first piece 
executed, It is created by the init$534$io procedure. It 
calls RQ$set$interrupt in line 7.325 to indicate to the 
iRMX 86 nucleus that it is an interrupt task. 

Once the initialization is complete, the task enters an 
infinite loop. The call to RQ$wait$interrupt in line 
7.322 causes the task to be put into the asleep state 
until an interrupt occurrence is signaled. The task will 
be returned to the READY state when an interrupt 
occurs, the interrupt handler is started, and the call to 
RQ$signal$interrupt is executed at line 7.312. The 
current interrupt level is then determined by polling 
the 8259 chip on the iSBC 534 board. Using the 
encoded level number, a unit is sent to the appropriate 
semaphore to indicate that an interrupt is pending. 

I/O TASK 

The final procedure that makes up this driver contains 
the code for the tasks that perform the actual I/O to 
the iSBC 534 board. The loop executed by each task 
starts by waiting at the request mailbox for an I/O 
request segment. When the segment is sent by the 
queue$534$IO procedure, its function code is checked 
(line 8.327, 8.332, 8.340). If the function is f$ 
detach$device, the task sends the segment to the 
response mailbox and then deletes itself. 

If the request was for a read, the task fills the buffer 
with input data. The call at line 8.334 waits for a unit 
at the semaphore which will indicate a receiver ready 
on the input line. When the unit is sent by the in- 
terrupt task, the character is read in, the pointers and 
counts are updated, and another unit is requested. 


The last request which is recognized by the I/O task is 
for a write operation. The code for this request is 
almost identical to the code for a read request. An 
interrupt from the transmitter is awaited, a character 
is output and the counts are updated in lines 8.341- 
8.346. 

Once the request is fulfilled, the message is sent to the 
response exchange in line 8.350. 

The configuration of this system is studied next. The 
code for the iSBC 534 driver is linked directly to the 
rest of the I/O system libraries. The entry point 
addresses for the queue$534$io, cancel$534$io, init$ 
534$io, and finish$534$io procedures are declared in 
the IOCNFG.A86 file on the I/O system disk. This file 
also contains the device unit information block (DUIB) 
structures for the four units on the iSBC 534 board. 
The unique information for the iSBC 534 device and 
the units on the device is contained in the device and 
unit information tables. Pointers to these tables are 
contained in the DUIB structures. All of this 
information is shown in Figure 24. 

The submit file used to build an I/O system using the 

— — - 

xo Oxxuvvxi. xli. • X ilC lilt; 

DRV534.LIB contains the object files generated by 
PL/M-86 and ASM-86 from the source code shown in 
modules 5-9. 


SUMMARY 

This application note is an introduction to the iRMX 
86 Operating System. The requirements of operating 
systems were studied along with traditional solutions. 
Following this, the iRMX 86 Operating System was 
introduced and its correlation with the requirements 
was studied. 

Later in the application note, the topic of system 
design was covered. Example solutions were studied to 
solidify a methodology for solving application 
problems and then the code for these solutions was 
discussed to gain insight into the details of imple- 
menting iRMX 86 systems. 

The purpose of a configurable, real-time, multi- 
purpose operating system is to provide a solid foun- 
dation for application software. The iRMX 86 system 
provides this foundation, giving the software engineer 
a means to quickly and easily implement new designs. 
In addition, the iRMX 86 architecture is the bridge to 
future technology providing the designer with an up- 
grade path to future hardware and software products. 
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ex tr n 

init534io: near 


extrn 

queue534io: near 


extrn 

cancel534io: near 


extrn 

finish534io: near 


; Duib (8 ) : i SBC 

534, unit 1 


define 

duib 

< 


& 


' i534. 1 ’ , 

name (14) 

& 


0 3H, 

suppSopt 

& 


00033H, 

file drivers 

& 



granul ar i ty 

& 


0»0, 

device size 

& 


3, 

device 

& 


1, 

unit 

& 



device unit 

& 


ini t534io , 

init$ io 

& 


finish534io. 

f i ni sh$ io 

& 


queue534io. 

queues io 

& 


cancel534io , 

cancels io 

& 


dev 534 info. 

device info 

& 


unit 534 1 info 

unit info 


&> 

; 534 device info 

dev_534 info dw 48H ; level 

db 61 ; priority 

db 04 0H ; base address 

; unit info: iSBC 534.0 

uni t_534_0_info db 4EH ; usart$cmd 

dw 8 ; baud rate 

; unit info: i SBC 534.1 

unit 534 1 info db 4EH ; usart$cmd 

~ ~ dw 8 ; baud rate 

; unit info: iSBC 534.2 

uni t_5 34_2_info db 4EH ; usart$cmd 

~ ~ dw 8 ; baud rate 

; unit info: iSBC 534.3 

unit 534_3 info db 4EH ; usartScmd 

dw 8 ; baud rate 


Figure 24. lOCNFG A86 File Entries for iSBC 534™ Driver 


; i os (date ,o r ig in) 

; Sample I/O System .csd file to link and locate an I/O System. 

} 

; This file links an I/O System with the timer included. 

t 

; This .csd file assumes the I/O System configuration module is 
; iocnfg.a86 (found on the release diskette). 

f 

; The origin parameter sets the low address of the I/O System; 

; all the segments are contiguous in memory. 

asm86 : f 1: iocnfg .a86 date(%0) pr int ( : f 5: iocnfg . 1 st) 

1 i nk86 & 

: f 1 : i os . 1 ib ( ioi ni t ) , & 

: f 1 : i ocnfg .ob j , & 

:f 1: ios.l ib, & 

:fl:drv534,lib, & 

:f4:rpifc.iib & 

to :fl:ios.lnk map pr i nt ( : f 1 : i os .mpl ) 
loc86 :fl:ios.lnk to :fl:ios map sc ( 3 ) pr i nt ( : f 1 : i o s .mp2 ) & 
oc (nol i ,nopl ,nocm,nosb) & 
o rd er ( cl asses ( code ,d ata , stack , memory) ) & 
addresses ( classes ( code ( %1 )) ) & 
segsi ze ( stack (0 ) ) 


Figure 25. Submit File for Generating an I/O System with the iSBC 534™ Driver 
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Module 1 

ISIS-II PL/M-86 V2.0 COMPILATION OF MODULE LISTENERMODULE 
OBJECT MODULE PLACED IN : FI : 1 i s ten . OB J 

COMPILER INVOKED BY: plm86 : FI : 1 isten .plm PR INT (: FI : LISTEN . LST) 

DEBUG COMPACT OPTIMIZE (3) ROM DATE (5/28/80 

1 1 istener$modul e : 

do ; 

^•kic1c-ki(1fk*'k1c‘k*'k*1t*‘k*1c1(1fk1i1c1c-k1c1c-k-kic1c*‘ic-k1c'k1c1c1c1e1e‘k1c1fk1cit1e'k1t1c1c1c1t1cicii1t1c1eific1t1ciiicic1i1c1iic 

LISTENER: TASK. 

This task creates segments, sends them to the input service 
job to be filled with input packet info. Upon response 
the info is checked to see what action needs to be taken. 

If a log$on request is sensed, a worker task, service 
mailbox, and response mailbox are created and the packet is 
sent along to the worker task. If a log$off is sensed all 
local reference to the workstation is deleted and the packet 
is sent along to tell the worker to delete himself. If an 
I/O request is sensed the station ID is checked to make 
sure it is logged on. If it is, the packet is sent along to 
the worker. If it isn't an error packet is sent back to the 
requesting workstation. 

1t'kifitii^1t1fititit1e'k1r1ric1eic1s1c1ficicifk1t1c1t1e1eic1c'k1c1c'it1s1e1t1f1r1tic1t1ciciciciciei€lcit1cicicici;ieic1cic'kitie1(ic'k1c1t1t1ey 

$include( :f2: common. 1 it) 

= $SAVE NOLIST 

$include(:fl:node.lit) 

= /* literal declaration of- node descriptor for list utilities */ 

11 1 = declare 

= node literally 'structure( 

= link$f word, 

= link$b word, 

= wo rk$stat ion$ID word, 

= service$mbox$ t word, 

= workers task$t word, 

= resp$mbox$t word)'; 

$include( : f l:lstutl .ext) 

= /* external declarations for list manipulation utilities */ 

= $save nolist 

$include( :fl:pointr.ext) 

= /* external declaration of pointerize procedure */ 

= $save nolist 

$include(:fl:r qpc k t . 1 i t ) 

= /* literal declaration for request packet structure */ 


24 1 = declare req$segment$struc literally 'structure( 

= funct word, 

= count word, 

= actual word, 

= ex$val word, 

= wor k$station$ID word, 

= cmd word, 

= share word, 

= mode word, 

= status word, 

= fileSname (64) byte, 

= buf (128) byte)'; 

$include( :f2:nucprm.ext) 

= $SAVE MOLIST 

321 1 workerStask: procedure external; 

322 2 end workerS task ; 
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Module 1, continued 

323 1 declare 

beg in$ 1 istener$ task$data byte public, 
beg in$wo rke r$ task Sdata byte external, 

1 og$on$ i n fo$mbox$ t token public, 
ex$val word, 

log$on$mbox$ name (7) byte data ( 6 , ' LOG$ON ' ) , 

packet$size literally '132', 

f$read literally '5', 

f$write literally '6', 

log$on literally '0', 

log$off literally 

no t$ logged$on literally '!', 

( root$ job$ t , i nput$ request$mbox$ t) token , 
(output$request$mbox$t,resp$mbox$t) token, 
(work$station$list$root$t,req$segment$t) token, 

(log$on$info$seg$ t ,d ummy$t , ws$desc$t) token, 
(req$segment$p,work$station$list$root$p) pointer, 

(log$on$ info$seg$p,data$seg$p,ws$desc$p) pointer , 

(req$segment based r eq$ segment$ p) req$segment$struc , 

( wo r k$sta t ion$ 1 ist$ roo t based wo rk$stat ion$ 1 ist$ root$p) node, 

( log$on$ info$seg based log$on$ info$ seg$ p) node, 

data$seg$p$o structure (of fset word, base word) at (0data$seg$p) , 
(ws$desc based ws$desc$p) node; 

324 1 r eturn$ er ro r$ to$WS : procedure; 

325 2 req$ segment . f unct= f$wr i te ; 

326 2 req$segment .status=not$logged$on; 

327 2 call r q$ send$messag e ( output$ request$mbox$ t , r eq$ segment$ t , 0 , @ ex$ val ) ; 

328 2 return; 

77Q 9 . 

330 1 Listener: procedure public; /* task */ 

331 2 log$on$ i n fo$mbox$ t= rq$cr eateSmai 1 box ( 0 , 0 ex$ val ) ; 

332 2 roo t$ j ob$ t= rq$get$ task $ tokens ( 3 ,§ ex$val ) ; 

333 2 input$ request$mbox$ t=rq$lookup$ob j ect ( 

/* job */ root$job$t, 

/* name */ P (9 , ' INPUT$RE0' ) , 

/* time limit */ 0FFFFH, 

/* status ptr */ @ex$val) ; 

334 2 output$ request$mbox$ t=rq$lookup$obj ect ( 

/* job */ root$job$t, 

/* name */ (a ( 1 0 , ' OUTPUT$REQ ' ) , 

/* time limit */ 0FFFFH, 

/* status ptr */ Pex$val) ; 

335 2 resp$mbox$ t= rq$crea te$ma i Ibox (0 , 0ex$ val ) ; 

336 2 wo r k$stat ion$ 1 is t$ roo t$ t=rq$create$ segment ( 1 6 , 0 ex$ val ) ; 

337 2 wo r k$stat ion$ 1 ist$ roo t$p=poi nter i ze ( wo r k$sta t ion$ 1 ist$ root$ t) ; 

338 2 wo r k$stat i on$ 1 ist$ root . 1 ink$f , 

work$station$l ist$ root .1 ink$b=work$station$l ist$ root$ t ; 

339 2 wo r k$sta t ion$ 1 ist$ roo t . wo r kstat ion$ ID=0 ; 

340 2 do forever; 

341 3 r eq$ segment$ t = rq$ receive$message ( 

/* mbox token */ i nput$ reques t$mbox$ t , 

/* time limit */ 0FFFFH, 

/* response ptr */ @dummy$t, 

/* status ptr */ gex$yal); 

342 3 req$ segment$ p=po i nte r i ze ( req$ segments t) ; 

343 3 if req$ segment . cmd= logSon then 

344 3 do; 
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345 4 

346 4 

347 4 

348 4 

349 4 

350 4 

351 4 


352 4 

353 4 

354 4 

355 4 

356 4 


Module 1, continued 

log$on$info$seg$t=rq$create$segment( 

/* size */ 16, 

/* status ptr*/ 0ex$val) ; 
log$on$info$ seg$p=po i nter i ze ( 
log$on$ info$ seg$ t) ; 
log$on$ info$seg .service$mbox$t= 
rq$create$mailbox (0 ,0ex$val) ; 
log$on$info$ seg . r esp$mbox$ t= 

rq$create$mailbox (0 ,@ex$val) ; 
log$on$info$seg.work$station$ID= 
req$segment .work$station$ID; 
data$seg$p=0beg in$wo r ker$ task$data ; 
log$on$info$seg.worker$task$t= 
r q$create$ task ( 

/* priority */ 200, 

/* start addr */ @wo r ker$ task , 

/* data seg ptr */ data$seg$p$o .base , 

/* stack pointer */ 0, 

/* stack size */ 500, 

/* task flags */ 0, 

/* status ptr */ 0ex$val) ; 

call rq$send$messag e ( 

/* mbox token */ log$on$ info$mbox$ t , 

/* object token */ log$on$ info$ seg$ t , 

/* response token */ resp$mbox$t, 

/* status ptr */ 0ex$val) ; 

log$on$info$ seg$ t= rq$ receive$message( 

/* mailbox token */ resp$mbox$t, 

/* time limit */ 0FFFFH, 

/* response token */ 0dummy$t, 

/* status ptr */ 0ex$val) ; 

call insert$on$list(work$station$list$root$t, 
log$on$ info$seg$ t) ; 
call rq$send$message ( 

/* mbox tok */ log$on$info$seg .service$mbox$t , 
/* obj tok */ req$segment$t , 

/* response */ 0, 

/* status */ 0ex$val) ; 


end ; 


357 3 

358 3 

359 4 

360 4 

361 4 

362 4 

363 5 

364 5 

36 5 5 


366 5 


else if req$ segment .cmd = log$off then 
do; 

ws$desc$t=search$list(work$station8list$root$t, 
req$segment . work$station$ID) ; 
if ws$desc$t = 0 then 

call return$error$to$WS; 

else 

do ; 

ws$descp=pointerize(ws$desc$t); 
call deletes from$ 1 ist ( 
ws$desc$ t) ; 
call rq$ sendSmessag e ( 

wsSdesc .service$mbox$t, 
r eq$ segments t , 

0 , 

0exSval) ; 

end ; 


367 4 


end ; 


else 

368 3 d o ; 

369 4 wsSdescS t=searchS 1 i St ( wo r kSsta t ionS 1 is tS roo tS t , 

reqS segment . wo r kSstati onS I D) ; 
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370 4 

371 4 

372 4 

373 5 

374 5 


375 5 

376 4 

377 3 

378 3 


if ws$desc$t=0 then 

call retarn$error$ to$WS; 

else 

do ; 

ws$descp=pointerize(ws$desc$t); 
call rq$send$message ( 

ws$desc .service $mbox$ t , 
req$segment$ t , 

0 / 

@ex$val) ; 

end ; 

end ; 

call rq$del ete$ segment ( req$segment$ t ,§ ex$ val) ; 
end; /* of do forever */ 


379 2 


end; /* of listener task */ 


380 1 end 1 istener$modul e ; 


MODULE INFORMATION: 

CODE AREA SIZE = 0281H 641D 

CONSTANT AREA SIZE = 0000H 0D 

VARIABLE AREA SIZE = 002BH 43D 

MAXIMUM STACK SIZE = 0018H 24D 

694 LINES READ 
0 PROGRAM ERROR (S) 

ijiNij (jr ri^/i'i-OD Is, umPi LATiUN 
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Module 2 

ISIS-II PL/M-86 V2.0 COMPILATION OF MODULE WORKERTASK 
OBJECT MODULE PLACED IN : FI : wo r ker . OB J 

COMPfLER INVOKED BY: plm86 : FI : worker .plm PRINT (: FI : WORKER. LST) 

DEBUG COMPACT OPTIMIZE(3) ROM DATE (5/28/8 0) 

1 worker$task: 

do ; 

y************************************************************************* 

WORKER$TASK: TASK. 

This module contains the code executed by the worker tasks. 

When started, the task goes to a mailbox to receive a segment 
containing initialization information. Using this information 
the task services a service mailbox performing any I/O functions 
requested of it. When a logSoff request comes in the worker 
task closes and detaches the file and deletes itself. 

*************************************************************************y 

$ includ e ( : f 1 : nucprm .ex t) 

= $SAVE NOLIST 

$ incl ud e ( : f 1 : i osys .ext) 

= $save nolist 

$include( :fl:node.lit) 

= /* literal declaration of node descriptor for list utilities */ 

= $save nolist 

$ include ( : f 2: common .lit) 

= $SAVE NOLIST 

$include( :fl:pointr.ext) 

= /* external declaration of pointerize procedure */ 

= $save nol ist 

$ includ e ( : f 1 : r qpckt .lit) 

= /* literal declaration for request packet structure */ 

= $save nolist 

239 1 declare 

read literally 
write literally '5', 
logSon literally '2*, 
log$off literally '3', 

( log$on$ info$mbox$ t ,o utputS request$mbox$ t) token external; 

240 1 workerStask: procedure reentrant public; 

241 2 declare 

(log$on$info$ seg$ t ,log$on$ resp$mbox$ t,resp$mbox$t, 
root$ job$t ,user$object$ t,pref ix$ t ,iors$t , 
serv ice$mbox$ t ,conn$ t , r eq$ seg$ t) token , 

( log$on$ info$p,req$seg$p) pointer , 

(req$seg based req$seg$p) req$segment$struc , 

(log$on$info based log$on$ info$p) node, 

(dummy$t ,ex$ val ,work$station$ID) word; 

1 og $on$ info$ seg $ t=rq$ receives mess age( 

/* mbox token */ logSonS infoSmboxS t , 

/* time limit */ 0FFFFH, 

/* response ptr */ @log$on$ respSmboxS t , 

/* status ptr */ §ex$val) ; 

log$on$info$p=pointerize(log$on$info$seg$t); 
service$mbox$t=log$on$info.service$mbox$t; 
respSmbox$t=log$on$info.resp$mbox$t; 
work$station$ID=log$on$info.work$station$ID; 


242 2 


243 2 

244 2 

245 2 

246 2 


cw.nici^nA 
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247 2 call rq$send$iriessage( 

/* mbox token */ log$on$ resp$mbox$ t , 

/* object token */ log$on$ info$seg$ t , 

/* response token */ 0, 

/* status ptr */ 0ex$val) ; 

248 2 roo t$ j ob$ t= rq$get$ task $ tokens ( 3 / 0 ex$ val ) ; 

249- 2 user $ob j ec t$ t= rq$ lookup$ob j ect ( 

/* job token */ root$job$t, 

/* name */ @ ( 1 1 , ' USER$OBJECT ' ) / 

/* time limit */ 0FFFFH, 

/* status ptr */ 0ex$val) ; 

250 2 pref ix$t=rq$lookup$object ( 

/* job token */ root$job$t, 

/* name */ @ (6 PREFIX' ) r 

/* time limit */ 0FFFFH, 

/* status ptr */ 0ex$val); 

251 2 doforever; 


252 3 r eq$ seg$ t= r q$ rece i ve$messag e ( 

/* mailbox token */ serv ice$mbox$ t , 

/* time limit */ 0FFFFH, 

/* response ptr */ 0dummy$t, 

/* status ptr */ 0ex$val) ; 

253 3 req$seg$p=pointer i ze { req$seg$t) ; 


254 3 

255 3 

256 4 


257 4 


258 4 

259 4 


260 4 


261 4 

262 4 

263 4 


264 4 


if req$seg .cmd=log$on then 

do ; 

call rof;a?ial‘tachf^filc>^ 

/* user object */ user$ob j ect$ t , 

/* prefix token */ prefix$t, 

/* pathname */ @req$seg . f ile$name , 

/* resp token */ resp$mbox$t, 

/* status ptr */ 0ex$val); 

iors$t=rq$receive$message( 

/* mbox token */ resp$mbox$t, 

/* time limit */ 0FFFFH, 

/* resp ptr */ 0dummy$t, 

/* status ptr */ 0ex$val) ; 

call rq$ deletes segment (iors$t,Pex$val) ; 

call rq$a$open( 

/* connection */ conn$t, 

/* mode */ reqSseg .mode , 

/* share */ req$ seg . sha re , 

/* resp token */ resp$mbox$t, 

/* status ptr */ 0ex$val); 

iors$ t= r q$ receives message( 

/* mbox token */ respSmboxSt, 

/* time limit */ 0FFFFH, 

/* resp ptr */ 0dummySt, 

/* status ptr */ 0exSval); 

call rqSdeleteSsegment ( iorsSt ,0exSval) ; 
reqSseg .status=0; 
call rqS sendSmessage { 

/* mbox token */ outputs requestSmboxS t , 
/* object token */ reqSsegSt, 

/* resp ptr */ 0, 

/* status ptr */ PexSval); 

end ; 


265 3 

266 3 

267 4 


else if reqSseg .cmd=logSoff then 
do ; 

call rqSaSclose( 

/* connection */ connSt, 

/* resp token */ respSmboxSt, 

/* status ptr */ 0ex$val); 
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268 4 


269 4 

270 4 


271 4 


272 4 

273 4 

274 4 

275 4 

276 4 


277 4 

278 4 

279 3 

280 3 

281 4 


282 4 


283 4 

284 4 

285 4 


286 4 

287 3 

288 3 

289 4 


290 4 


291 4 


Module 2, continued 

iors$t= rq$ receive$messag e ( 

/* mbox token */ resp$mbox$t, 

/* time limit */ 0FFFFK, 

/* resp ptr */ ^dammy$t, 

/* status ptr */ ®ex$val); 

call rq$delete$segment ( iors$ t ,@ex$val) ; 

call rq$a$delete$connection ( 

/* connection */ conn$t, 

/* response ptr */ resp$mbox$t, 

/* status ptr */ 0ex$val) ; 
iors$ t=rq$rece ive$ message ( 

/* mbox token */ resp$mbox$t, 

/* time limit */ 0FFFFH, 

/* response ptr */ Pdummy$t, 

/* status ptr */ 0ex$val) ; 

call rq$delete$segment(iors$t,0ex$val) ; 

call rq$delete$mailbox (service$mbox$t ,0ex$val) ; 

call rq$delete$mailbox ( resp$mbox$t ,0ex$val) ; 

r eq$ seg ,s tatus=0 ; 

call rq$send$message ( 

/* mbox token */ o utput$ request$mbox$ t , 

/* object token */ req$seg$t, 

/* resp token */ 0, 

/* status ptr */ 0ex$val) ; 

call rq$delete$ task (0 ,0ex$val) ; 

end ; 

else if req$ seg .cmd= read then 

do ; 


call rq$a$read( 

/* connection */ conn$t, 

/* buf ptr */ 0req$ seg .buf , 

/* count */ req$seg .count , 

/* resp token */ resp$mbox$t, 

/* status ptr */ 0ex$val) ; 

iors$t=rq$receive$message( 

/* mbox token */ resp$mbox$t, 

/* time limit */ 0FFFFH, 

/* resp ptr */ 0dummy$t, 

/* status ptr */ 0ex$val) ; 

call rq$delete$segment(iors$t,0ex$val) ; 
req$seg .status=0 ; 
call r q$ send$messag e ( 

/* mbox token */ o utput$ request$mbox$ t , 

/* object token */ req$seg$t, 

/* resp token */ 0, 

/* status ptr */ 0ex$val) ; 

end ; 

else if req$seg .cmd=wr i te then 

do ; 


call rq$a$write( 

/* connection */ conn$t, 

/★ Kn^ */ flrcarr<^c:c»rT.Hnf_ 

/* count */ req$ seg .count , 

/* resp token */ resp$mbox$t, 

/* status ptr */ 0ex$val); 

i or s$ t=rq$ rece i ve$messag e ( 

/* mbox token */ resp$mbox$t, 

/* time limit */ 0FFFFH, 

/* resp ptr */ 0dummy$t, 

/* status ptr */ 0ex$val) ; 

call rq$delete$segment-( iors$t ,0ex$val) ; 


A CM n-1 Citn A 
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Module 2, continued 

292 4 call r q$ send$message ( 

/* mbox token */ outpat$ request$mbox$ t , 
/* object token */ req$seg$t, 

/* resp token */ 0, 

/* status ptr */ pex$val) ; 

293 4 end; 

end; /* of do forever */ 

295 2 end; /* of task */ 

296 1 end workerStask; 


MODULE INFORMATION: 


CODE AREA SIZE 

0288H 

648D 

CONSTANT 

AREA SIZE = 

0000H 

0D 

VARIABLE 

AREA SIZE = 

0000H 

0D 

MAXIMUM 

STACK SIZE = 

0034H 

52D 


717 LINES READ 
0 PROGRAM ERROR (S) 

END OF PL/M-86 COMPILATION 
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Modules 


ISIS-II MCS- 

86 MACRO 

ASSEMBLER V2 . 0 

ASSEMBLY 

OF MODULE POINTR 

OBJECT MODULE PLACED 

IN :Fl:POINTR. 

OBJ 



ASSEMBLER INVOKED BY: 

; asm86 :fl:poi 

ntr.a86 debug pr ( : f 5 : po i nt r . 1 st) 

LOC OBJ 

LINE 

SOURCE 





1 

$ t i tl e ( po i nter i ze Utility) 


0004 

2 

arg off 

equ 

4 

; set args f( 


3 





— 

4 

code 

segment 

word public ' 

CODE ' 

— 

5 

Ci 

code 

end s 




n 

7 

eg ro up 

g roup 

code 


— 

8 

cod e 

segment 




9 


assume 

cs: egroup 



10 





0000 

11 

po i nt er i ze 

proc 

near 



12 


publ ic 

po i nter i ze 


0000 55 

13 


push 

bp 

; save 

0001 f^BEC 

14 


mov 

bp, sp 

; mark stack 


15 




+ arg off + 0] 

0004 [] 

1 6 

token 

equ 

word ptr [bp 

17 





0003 8E4604 

18 


mov 

es , token 

; get base 

0006 33DB 

19 


xo r 

bx , bx 

; zap offset 


20 




; restore st 


21 

§ 

mov 

sp, bp 

0008 5D 

22 


pop 

bp 


0009 C20200 

23 


ret 

2 



24 

po i nt er i ze 

endp 



— 

25 

code 

end s 




26 

end 





ASSEMBLY COMPLETE, NO ERRORS FOUND 


DELUXE" 
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Module 4 

ISIS-II PL/M-86 X167 COMPILATION OF MODULE LISTUTI LITI ESMODULE 
OBJECT MODULE PLACED IN : FI : 1 stut 1 . OB J 

COMPILER INVOKED BY: plm86 : FI : 1 stut 1 . plm PRINT (: F5: LSTUTL. LST) 

DEBUG COMPACT OPTIMIZE(3) ROM DATE (3/7/80) 

1 1 ist$util ities$module: 

do ; 

yicic1i1c:k'k-k-k*-k‘kic'k1e'k1e'k-k1eic-k-k'kif1t*1cif1e1f1e'kic-k1f1c1f1eitie1e*1t1c-it1e1iic1i1e1c1eit1tii1r'k'k1c1t1c1c‘k1c1c'k1c1c'k1c1c1c 

LIST$UTILITIES : PUBLIC PROCEDURES. 

This module contains three list manipulation utilities. 

Insert$on$ 1 ist takes the given node and inserts it on the 
list indicated by the root node parameter. Delete$from 
list unlinks the indicated node from the list it is 
linked to. Search$list scans the list from the root looking 
for the indicated node. If found, the token for the node 
is returned. If not found, a zero is returned. 

icicicicieicieicicis'k'kicieifititikierk'k'k'kicieiticirieieieieicicicicic'k'k'kie'k'kic'k'k'kiticieieic'kit'kiticicic'kitic'k'kiciticit'k'kic'tc^ 

$include( : f 4:common.l it) 

= $SAVE NOLIST 

$include(:fl:node.lit) 

= /* literal declaration of node descriptor for list utilities */ 

= $save nolist 

$include(:fl:pointr.ext) 

= /* external declaration of pointerize procedure */ 

$save nolist 

Insert$on$ 1 ist : procedure( root$ t ,new$desc$ t ) reentrant public; 
declare 

( root$ t ,new$desc$ t,fwd$desc$t) token, 
(root$p,new$desc$p,fwd$desc$p) pointer, 

(root based root$p) node, 

(newSdesc based new$desc$p) node, 

(fwdSdesc based fwd$desc$p) node; 

root$p=pointeri ze ( roots t) ; 
new$desc$p= pointer i ze (newSdescS t) ; 
f wd$desc$ t=root.link$f; 
fwd$desc$p=pointerize(fwd$desc$t); 
root.l inkSf=new$desc$t; 
newSdesc.l ink$f=fwd$descSt; 
newSdesc .1 inkSb=rootSt; 
fwdSdesc . 1 i nk$b=newSdescS t ; 
return ; 

end; /* insertSonSl ist */ 

Del eteS f romS 1 i St : procedure (descSt) reentrant public; 

declare 

descSt token, 

(desc$p,bSdesc$p,f$descSp) pointer, 

(desc based descSp) node, 

(bSdesc based bSdescSp) node, 

( fSdesc based fSdescSp) node; 

descSp=pointerize (descSt) ; 
b$ desc$p= pointerize (desc. 1 inkSb) ; 
f$desc$p=pointerize(desc.link$f); 
bSdesc.linkSf=desc.link$f; 
fSdesc.linkSb=desc.link$b; 
return; 


15 1 

16 2 


17 2 

18 2 

19 2 

20 2 
21 2 
22 2 

23 2 

24 2 

25 2 

26 2 

27 1 

28 2 


29 2 

30 2 

31 2 

32 2 

33 2 

34 2 
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Module 4, continued 

35 2 end; /* del et e$ f roin$ 1 i St */ 

36 1 search$list: procedure ( root$t ,WS$ID) word reentrant public; 

37 2 declare 

( root$ t , WS$I D) word, 

( s$desc$p,root$p) pointer, 

(root based rootSp) node, 

(s$desc based s$desc$p) node, 

s$desc$p$o structure (offset word, base word) at ( @s$desc$p) , 
temp pointer; 

38 2 s$desc$p=pointer i ze ( roots t) ; 

39 2 nextSnode: 

if sSdesc .work$station$ID=WS$ID then 

40 2 return sSdescSpSo .base ; 

41 2 if sSdesc . 1 inkSf = rootSt then 

42 2 return0; 

43 2 temp=pointeri ze ( sSdesc .1 inkSf ) ; 

44 2 s$desc$p=temp; 

45 2 goto nextSnode; 

46 2 end; /* searchSlist */ 

47 1 end 1 istSuti 1 itiesSmodul e; 


MODULE INFORMATION: 

CODE AREA SIZE = 00FEH 254D 

CONSTANT AREA SIZE = 0000H 0D 

VARIABLE AREA SIZE = 0000H 0D 

MAXIMUM STACK SIZE = 0018H 24D 

114 LINES READ 
0 PROGRAM ERROR (S) 

END OF PL/M-86 COMPILATION 
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Module 5 

ISIS-II PL/M-86 X167 COMPILATION OF MODULE STARTANDF INISH 
OBJECT MODULE PLACED IN : FI : s t r f i n . OB J 

COMPILER INVOKED BY: plm86 : FI : st r f in .plm PR INT { : F5: STRFIN. LST) 

DEBUG COMPACT OPTIMIZE{2) ROM DATE (4/2 8/8 0) 


1 


start$and$ finish : 
do ; 


INIT$534$IO and FINISH$534$IO: PUBLIC PROCEDURES. 


This module contains the init$534$IO and the FINISH$534$IO 
procedures which can be called by the RMX/86 I/O system. STARTSIO 
is called just before the first a ttachSdev ice is performed. 

It will create the interrupt task and the eight interr upt$pend ing 
semaphores. The FINISH$IO procedure is called just after the 
last detach$device is performed. It undoes everything the START$IO 
call did. 


$include( : f 4:nucprm.ext) 

= $SAVE NOLIST 

$include( :f4: common .lit) 

= $SAVE NOLIST 

$include( :fl:duib.lit) 

= /* duib structure definition */ 

= Ssave no! i st 

$include(:f4:nerror.lit) 


= $SAVE NOLIST 

$include( :fl:pointr.ext) 

= /* external declaration of pointerize procedure */ 

= $save nolist 

$include(:fl:retdta.lit) 

= /* literal declaration of retSdata structure for init$534Sio */ 

= $save nolist 


314 

1 

ini t$534$liw: proced ure (data$p) external; 

315 

2 

declare data$p pointer; 

316 

2 

end init$534$hw; /* initializes 534 hardware 

317 

1 

int$534$task : procedure external; 

318 

2 

end int$534$task ; 

319 

1 

declare 


beg in$ int$ 534$data byte external, 

IO$base$addr byte public, 
int$level word public, 
g$ret$data$p pointer public, 
req$mbox$t token public; 

320 1 init$534$IO: procedure(duib$p,ret$data$t$p,status$p) reentrant publ ic ; 


321 2 declare 

(duib$p,ret$data$t?p,statusSp) pointer , 
(duib based duibSp) dev$ un i t$ in fo? bJ. oc k , 
(ret$data$t based ret$data$ tSp) token, 
(status based statusSp) word, 
dev$info$p pointer, 

devSinfo based devSinfoSp structuref 
level word, 
priority byte , 

IO$base$addr byte). 


38 


AFN-01540A 




AP-86 


Module 5, continued 


322 2 


323 2 

324 2 

325 2 

326 2 

327 2 

328 2 

329 2 


330 2 

331 2 

332 2 

333 2 

334 2 

335 2 

336 2 

337 2 


338 2 

339 2 

'34 0 2 

‘341 3 


342 3 


exSval word, 
data$seg$p pointer, 

data$seg$p$o str uc ture ( of f set word, base word) at (Pdata$seg$p) , 
(i,j) byte; 

declare 

ret$data$p pointer, 

retSdata based ret$data$p structure(ret$data8struc); 

ret$data$ t=rq$create$segnent ( si ze ( retSdata) ,Pex$val) ; 
if exSval <> 0 then 
goto err0; 

g$ret$data$p,ret$data$p=pointerize(ret$data$t); 
dev$ info$p=duib .dev$ info$p; 

IO$base$addr,ret$data.IO$base=dev$info.IO$base$addr; 
int$level ,ret$data.i nt$ level=dev$ i nfo . 1 evel ; 

/* create the request mailbox */ 

ret$data.request$mbox$t,r eq$mbox$ t 
= rq$create$mailbox(0,(aex$val); 
if exSval <> 0 then 
goto errl; 

ret$data.resp$mbox$t=rq$create$mailbox(0,Pex$val); 
if ex$val <> 0 then 

goto err2; /* clean up partial creation */ 

d ata$ seg$ p=Pbeg in$int$534$data; 
ret$data.int$task$t=rq$create$task( 

/* priority */ dev$ info .pr ior i ty , 

/* entry point */ 0int$534$task , 

/* data segment */ data$seg$p$o .base , 

/* stack pointer */ 0, 

/* stack size */ 400, 

/* task flags */ 0, 

/* status pointer */ PexSval) ; 
if ex$val <> 0 then 

goto err3; /* can't create, clean up partial creation */ 

do i=0 to 7; /* create semaphores */ 

ret$data.int$sema(i) =rq$create$ semaphore ( 

/* initial value */ 0, 

/* max value */ 1, 

/* priority queue */ 1, 

/* status ptr */ Pex$val); 

if exSval <> 0 then 


343 3 goto err4; /* clean up partial creation */ 

344 3 end; 

345 2 call init$534$hw( retSdataSp) ; 

346 2 status=E$OK; 

347 2 return; 


348 2 


349 3 

350 3 

351 2 

352 2 

353 2 

354 2 


er r4 : 


do j=0 to i; 

call r qSdel et e$ semapho re ( retSde ta . i ntS sema ( j ) ,status$p) ; 

end ; 

call rq$ resets interrupt (devS info . 1 evel , stat usSp) ; 
er r 3 : 

call r qSdel et eSma i 1 box ( retSdata . r espSmboxS t , sta tusS p) ; 


er r2 : 

call r qSdel eteSma i 1 box ( retSdata . requestSmboxS t , sta tusS p) ; 


er r 1 : 

call rqSdeleteSsegment ( retSdataS t ,statusSp) ; 
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Module 5, continued 


355 2 

356 2 

357 2 

358 1 

359 2 


360 2 

361 2 

362 2 

363 2 

364 2 

365 2 

366 3 


367 3 

368 2 

369 2 

370 2 

371 1 


er r0 : 

status=ex$ val ; /* restore original status condition */ 
return; 

end; /* of procedure */ 


f i ni sh$ 5 34 $I 0 : proced ur e ( du i b$ p , r et$da ta$ t) reentrant public; 
declare 

duibSp pointer, 
dev$info$p pointer, 

dev$info based dev$info$p structure( 
level word, 
priority byte, 

IO$base$addr byte) , 
ret$data$p pointer, 

retSdata based ret$data$p structure ( ret$data$struc) , 
(duib based duibSp) dev$ uni t$ i nfo$ block , 
ret$data$t token, 
i byte, 
exSval word; 


dev$info$p=duib.dev$info$p; 

ret$data$p=pointerize(ret$data$t); 

call rq$reset$interrupt (dev$ info . 1 evel , P ex$ val ) ; 

call rqSdel eteSma i Ibox ( ret$data . r equest$mbox$ t ,P ex$ val ) ; 

call rq$delete$mailbox ( ret$data .respSmboxSt ,Pex8val) ; 

do i=0 to 7; 

call rqSdel ete$ semaphore ( 
r et$data . i nt$sema ( i ) , 

0 ex $ val ) ; 

end ; 

call ro8dp!ptp5)=:°^(mppf■'•"P^^<^3^=''~^ 


return; 

end; /* of procedure */ 
end sta rt$ and$ finish; 


MODULE INFORMATION: 


CODE AREA SIZE 
CONSTANT AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
671 LINES READ 
0 PROGRAM ERROR (S) 


0220H 

544D 

0000H 

0D 

0009H 

9D 

0034H 

52D 


END OF PL/M-86 COMPILATION 
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Module 6 

ISIS-II PL/M-86 X167 COMPILATION OF MODULE QUE UE 53 ^ I OM ODULE 
OBJECT -MODULE PLACED IN : FI : q ue i o . OB J 

COMPILER INVOKED BY: plm86 : FI :que io .plm PRINT (: F5: OUEIO. LST) 

DEBUG COMPACT OPTIMIZE (2) ROM DATE (4/2 5/8 0 ) 


1 


315 1 

316 2 

317 1 

318 1 

319 2 


queue$53^$io$module: 
do ; 


0UEUE$534$IO, PUBLIC PROCEDURE. 

This procedure is called by the I/O System to queue 
an I/O request to the 534 board. The function field 
in the lORS is used to determine what specific action 
to take. Module also contains a dummy cancel $ 5 34 $ io 
proced ur e . 


$include( :f4:nucprm.ext) 

$SAVE NOLIST 
$include( :f4:common.l it) 

$SAVE NOLIST 
$include( :f4:nerror,l it) 

$SAVE NOLIST 

$include( :fl:pointr.ext) 

/* external declaration of pointerize procedure */ 

$save nolist 
$include( :fl:duib.l it) 

/* duib structure definition */ 

$save nolist 
$include( :fl: iors.l it) 

/* literal declaration for iors */ 

$save nolist 

$include{ :fl:retdta .1 it) 

/* literal declaration of ret$data structure for init$534$io */ 
$save nolist 


io$534$task: procedure external; 
end io$534$task; 

declare 

beg in$ io$ taskSdata byte external; 

queues 534$io : procedure ( iors$t,duib$p,ret$data$t) reentrant public; 


declare 

{ iorsSt ,ret$data$t) token, 
data$seg$p pointer, 

data$seg$p$o structure (of fset word, base word) at (0data$seg$p) , 
IDDR 1 iterally ' 2AH' , 

(duib$p,ret$data$p,iors$p) pointer. 


(retSdata based retSdataSp) structure ( retSdataSstruc) 


(iors based iorsSp) IO$request$ resui tSsegment , 
ioStaskSt token, 
unit$info$p pointer, 

units info based units in foSp structure( 
usartScmd byte, 
ba udS rate wo rd) , 
i byte, 

dummySt token, 
exSvai word; 
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320 

2 

Module 6, continued 

iorsSp=pointerize(iors$t) ; 

321 

2 

ret$dataSp=pointerize(ret$data$t); 

322 

2 

if iors.funct > 7 then 

323 

2 

goto badSrequest; 

324 

2 

do case iors.funct; 

325 

3 

do; /* case 0 — read */ 

326 

4 

iors.auxSp=retSdata$p; 

327 

4 

call rqSsend$message( 

328 

4 

/* mbox */ retSdata .requestSmboxS t 
/* token */ iorsSt, 

/* resp */ 0, 

/* status ptr*/ PexSval); 
return ; 

329 

4 

end ; 

330 

3 

do; /* case 1 — write */ 

331 

4 

iors.auxSp=ret$data$p; 

332 

4 

call rqSsend$message( 

333 

4 

/* mbox */ retSdata . requestSmboxS t 
/* token */ iorsSt, 

/* resp */ 0, 

/* status ptr*/ PexSval) ; 
return ; 

334 

4 

end ; 

335 

3 

do; /* case 2 — seek (illegal) */ 

336 

4 

goto badSrequest; 

O J / 

4 

C 1 1 ^ 

338 

3 

do; /* case 3 — special (illegal) */ 

339 

4 

goto badSrequest; 

340 

4 

end ; 

341 

3 

do; /* case 4 — a t tachSdev ice */ 

342 

4 

/* create two I/O tasks */ 

dataSsegSp=0beg inSlOStaskSdata; 

343 

4 

do i=0 to 1; 

344 

5 

ioStaskSt= rqScrea teS task ( 


/* priority */ 150, 

/* entry pnt */ @io$534$task , 

/* data seg */ data$seg$p$o .base , 

/* stack ptr */ 0, 

/* stack size */ 500, 

/* task flags */ 0, 

/* status ptr */ 0ex$val); 

345 5 end; 

346 4 units infoSp=duib. units info$p; 

347 4 doi=0to3; 

348 5 output ( rets data . usartS cmdS po rt ( i or s . un i t )) =0 ; 

349 5 end; 

350 4 o utput ( r etSda ta . usa r t$ cmdS po r t { i o r s . un i t ) ) =4 0H ; 

351 4 o utput ( rets d a ta . usa rtS cmdS po rt ( ior s . un i t )) = 

unitSinfo .usartScmd; 

352 4 o utput ( rets d ata . usartS cmdS po rt ( i or s . un i t) ) =2 7H ; 

353 4 output ( retSdata . IOSbase+0CH) =0 ; /* select cntrl blk */ 

354 4 o utput ( retSdata . t imerS cmdS po rt ( i o r s . un i t )) - 

retSdata. t imerS cmd (iors.unit) ; 

355 4 o utput ( retSd ata . t imerS loads po rt ( i or s . un i t )) = 

low(unitSinfo.baudSrate) ; 

356 4 output(retSdata.timer$load$port(iors.unit))= 

high(unitSinfo.baudSrate) ; 


42 


AFN-01540A 



AP-86 


357 4 


359 4 

360 4 

361 4 

362 3 


363 4 


364 4 


365 4 


366 4 


367 4 

368 4 

369 3 

370 4 

371 4 

372 3 

373 4 

374 4 

375 3 

376 2 

377 2 

378 2 

379 2 

380 2 


381 2 

382 2 

383 1 

384 2 


385 2 


Module 6, continued 

output ( ret$data . IO$base+0DH) =0 ; /* select data blk */ 
/* accept interrupt and character from receiver */ 
d ummy $ t = r q$ rece i ve$ un i t s ( 

/* sema */ ret$data . i nt$ sema ( 2 * iors.unit), 

/* units */ 1, 

/* time$out */ 0, 

/* status */ ^ex$val); 

i=input ( retSdata »usart$data$port ( iors.unit )); 
goto ok$send$ resp; 

end ; 

do; /* case 5-- detachSdevice */ 

/* send two copies of the detach request to the request mailbox. 
This will signal to two of the I/O tasks that they are to 
delete themselves */ 

call rq$ sendSmessage ( 

/* mbox token */ ret$data . r equest$mbox$ t , 

/* object token */ iors$t, 

/* response */ ret$data . r esp$mbox$ t , 

/* status */ PexSval) ; 

dummy$t=rq$ receive$roessage ( 

/* mbox token */ retSdata . r esp$mbox$ t , 

/* time$limit */ 0FFFFH, 

/* response ptr */ 0dummy$t, 

/* status ptr */ Pex$val) ; 
call rq$send$message{ 

/* mbox token */ ret$data . request$mbox$ t , 

/* object token */ iorsSt, 

/* response */ ret$data . resp$mbox$ t , 

/* status */ Pex$val) ; 

dummy$t=rq$ rece ive$mes sage ( 

/* mbox token */ ret$data . r esp$mbox$ t , 

/* time$limit */ 0FFFFH, 

/* response ptr */ PdummySt, 

/* status ptr */ PexSval) ; 
goto ok$send$ resp; 

end ; 

do; /* case 6-- open */ 
goto ok$send$ resp; 

end ; 

do; /* case 7 — close */ 
goto ok$send$ resp; 

end ; 

end; /* do case */ 
return ; 
bad$ request ; 

iors.status=I DDR ; 
goto send$resp; 
ok$send$ resp : 

iors.status=E$OK; 
send$ resp : 

call r q$ send $message(iors. res p$mbox,iors$t,0,Pex$val) ; 
return; 

end; /* procedure */ 

cancels 534 $io : proced ur e ( iorsS t ,d uibS p , r etSdataS t) public; 
declare 

( iorsS t ,ret$data$t) token, 
duibSppointer; 

return; 


ACM AHRiiAA 


4 .? 




AP-86 


Module 6, continued 

386 2 end; 

3 87 1 end que ue$534$io$module; 

MODULE INFORMATION: 

CODE AREA SIZE = 020CH 524D 

CONSTANT AREA SIZE = 0000H 0D 

VARIABLE AREA SIZE = 0000H 0D 

MAXIMUM STACK SIZE = 0038H 56D 

729 LINES READ 
0 PROGRAM ERROR rsi 

END OF PL/M-86 COMPILATION 
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Module 7 

ISIS-II PL/M-86 V2.0 COMPILATION OF MODULE INTERRUPT534MODULE 
OBJECT MODULE PLACED IN : FI ; i nt 5 34 . OB J 

COMPILER INVOKED BY: plm86 : FI : i nt5 34 . plm PRINT (: FI : INT534 . LST) 

DEBUG COMPACT OPTIMIZE(2) ROM DATE ( 5/2 8/8 0 ) 

$nointvector 

1 Interrupt$534$module: 

do ; 

/*********************************************************************** 

INT$534$TASK and INT$534$HND; 

PUBLIC PROCEDURES: 

This module contains the interrupt handler and the interrupt 
task for the 534 board interrupt. The handler simply calls 
signal$ interrupt and the task reads the ISR on the 534 
board's 8259 and sends a unit to one of eight interrupt$ 
pending semaphores to signal the occurrence of the event. 

***********************************************************************/ 

$include( :f 2:nucprm.ext) 

= $SAVE NOLIST 

$ includ e( : f 1: retd ta . 1 i t) 

= /* literal declaration of ret$data structure for init$534$io */ 

= $save nolist 

$ include ( : f 2: common .1 it) 

= $SAVE NOLIST 

308 1 declare 

beg in$ int$534$data byte public^ 
g$ret$data$p pointer external, 

IO$base$addr byte external, 
intSlevel word external; 

309 1 int$534$hnd: procedure interrupt 5; 

310 2 declare 

1 word, 
ex$val word; 

311 2 l=rq$get$level (@ex$val) ; 

312 2 call rq$signal$interrupt(l,@ex$val) ; 

313 2 return; 

314 2 end; 

315 1 int$534$task : procedure reentrant public; 

316 2 declare 

IO$534$base byte, 
int$534$level word, 
ret$data$p pointer, 

ret$data based ret$data$p structure ( ret$data$struc) , 

cSlevel byte, 

ex$val word; 

eoi literally '20H'; 

317 2 IO$534 $base=I 0$base$addr ; 

318 2 int$534$level=int$level; 

319 2 ret$data$p=g$ ret$data$p; 

320 2 call rq$set$ interrupt { 

/* level */ int$ 534$level , 

/* flags */ 1, 

/* entry point */ interrupt$ptr ( int$534$hnd) , 

/* data segment */ 0, 

/* status ptr */ 0ex$val) ; 
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Module 7, continued 


321 2 

322 3 

323 3 

324 3 

325 3 

326 3 

327 3 

328 2 


do forever; 

call rq$wa i t$ i nter r upt ( int$ 5 34 $level ,0 ex$ val ) ; 
output (IO$534$base+8)=0CH; 
c$level=input ( IO$534$base+8) and 07H; 

call rq$ send$ uni ts ( ret$data . i nt$ sema ( c$ level ) ,l,@ex$val) ; 
output ( IO$534$base+8) =EOI ; 
end; /* of do forever */ 
end; /* of procedure */ 


329 1 end interrupt$534$module; 


MODULE INFORMATION; 


CODE AREA SIZE = 00B5H 181D 

CONSTANT AREA SIZE = 0000H 0D 

VARIABLE AREA SIZE = 0005H 5D 

MAXIMUM STACK SIZE = 0026H 38D 

541 LINES READ 
0 PROGRAM ERROR (S) 

END OF PL/M-86 COMPILATION 
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Module 8 

ISIS-II PL/M-86 X167 COMPILATION OF MODULE I0534TASKM0DULE 
OBJECT MODULE PLACED IN : FI : i o task . OB J 

COMPILER INVOKED BY: plni86 : FI : iotask .plm PRINT {: F5: lOTASK. LST) 

DEBUG COMPACT OPTIMIZE (2) ROM DATE (4/25/8 0 ) 


1 


314 1 


315 1 

316 2 


317 2 

318 3 


319 3 

320 3 

321 3 


io$534$task $modul e : 
do ; 


IO$534$TASK: TASK. 


This task receives lORS segments from the queueSio 
procedure and performs the necessary input or 
output operations on the iSBC 534 board. 

***********************************************************************/ 

$ incl ud e ( : f 4 : common .lit) 

$SAVE NOLIST 
$include( :fl:pointr.ext) 

/* external declaration of pointerize procedure */ 

$save nolist 
$ include ( : f 4: nucprm.ex t) 

$SAVE NOLIST 
$ incl ud e( :f4:nerror.l it) 

$SAVE NOLIST 
$include(:fl:retdta.lit) 

/* literal declaration of retSdata structure for init$534$io */ 

$save nolist 
$include( :fl:iors.lit) 

/* literal declaration for iors */ 

$save nolist 


declare 

begin$ io$task$data byte public, 
req$mbox$t token external, 
f $detach$device literally '5', 
f$read literally *0', 
f$write literally 

IO$534$task: procedure reentrant public; 


declare 

iors$t token, 
iorsSp pointer, 

iors based iors$p IO$request$ resul tSsegment , 

ex$val word, 

resp$t token, 

buff$p pointer, 

buf based buff$p (1) byte, 

i wo rd , 

unit byte, 

ret$data$p pointer, 

tec-^)QaLa ud^jeu ttfupdata$p structure (ret$dat3$str 
c$val word; 


do forever; 

iors$t=rq$receive$message( req$mbox$t,0FFFFH,Presp$t,iaex$val); 

/* check for non-existence of mailbox. IF last device has been detached 
the mailbox will be deleted In this case, delete tfiyself */ 

if ex$val= ESexist then 

call r q$del ete$ task ( 0 , (3 ex$ val ) ; 
i or s$ p=po i nt er i ze { ior s$ t) ; 
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322 3 

323 3 

324 3 

325 3 

326 3 

327 3 

328 3 

329 4 


3 30 4 

331 4 

332 3 

333 3 

334 4 


335 4 

336 4 

337 4 

338 4 

339 4 

340 3 

341 3 

342 4 


343 4 

344 4 

345 4 

346 4 

347 4 

349 3 

350 3 

351 3 


352 2 


353 1 


Module 8, continued 

buff$p=iors.buff$p; 
uni t= iors . unit; 
iors.actual=0 ; 
i = 0; 

ret$data$p=iors.aux$p; 

if iors.funct = f $detach$device then 
do ; 

call rq$send$message{ 

/* mbox token */ resp$t, 

/* object token */ iors$t, 

/* response token */ 0, 

/* status ptr */ PexSval); 
call rq$del ete$ task ( 0 , Pex$ val ) ; 

end ; 

if iors.funct= f$read then 
do while iors.count >0; 

c$val=rq$receive$units( 

/* sema */ r et$da ta . i nt$ sema ( 2 *un i t ) , 

/* units */ 1, 

/* time */ 0FFFFH, 

/* status*/ 0ex$val) ; 

buf ( i )= input ( retSdata . usa rt$data$ po rt ( un i t) ) and 07FH; 
i = i + 1 ; 

iors.count=iors.count-l; 

iors.actual=iors.actual+l; 

end ; 

else if iors.funct= fSwrite then 
do while iors.count >0; 

c$val=rq$receive$units{ 

/* sema */ retSdata . i nt$ sema ( 2 *un i t+1 ) , 

/* units */ 1, 

/* time */ 0FFFFH, 

/* status*/ PexSval); 

output(ret$data.usart$data$port(unit) )=buf(i) ; 
i = i + 1 ; 

iors.count=iors.count-l; 

iors.actual=iors.actual+l; 

end ; 

iors. statu s=E$OK; 
iors .done=T RUE ; 

call r qSsendSmessag e ( ior s . r espSmbox , i or s$ t , 0 , @ exS val ) ; 
end; /* of do forever */ 

end; /* of procedure */ 

end io$534 StaskSmodule; 


MODULE INFORMATION: 

CODE AREA SIZE = 018DH 397D 

CONSTANT AREA SIZE = 0000H 0D 

VARIABLE AREA SIZE = 0001H ID 

MAXIMUM STACK SIZE = 0028H 40D 

624 LINES READ 
0 PROGRAM ERROR (S) 

END OF PL/M-86 COMPILATION 
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Module 9 

ISIS-II PL/M-86 X167 COMPILATION OF MODULE INIT534HW 
OBJECT MODULE PLACED IN : FI : i ni thw. OB J 

COMPILER INVOKED BY: pim86 : FI : i ni thw. plm PRINT {: F5 : INITHW . LST) 

DEBUG COMPACT OPTIMIZE (2) ROM DATE (4/25/8 0) 

1 init$534$hw: 

do ; 

/*********************************************************************** 

init$534$hw; PUBLIC PROCEDURE. 

This procedure initializes the iSBC 534 hardware and 
sets up the device dependent fields of the ret$data 
segment which will be used by the queueSio procedures. 

It**********************************************************************/ 

$ incl ud e ( ; f 4 : common .lit) 

= $SAVE NOLIST 

$include(:fl:retdta.lit) 

= /* literal declaration of ret$data structure for init$534$io */ 

= $save nolist 

12 1 init$534$hw: proced ure ( retSdataSp) reentrant public; 

13 2 declare 

ret$data$p pointer, 

ret$data based ret$data$p structure ( ret$data$st rue) , 

(base,i) byte; 


14 

2 

base=ret$data.io$base; 



15 

2 

output { base+0FH) =0 ; /* 

board reset 

*/ 

16 

2 

output (base+0DH) =0 ; /* 

select data 

block */ 

17 

2 

output (base+8 ) =1 6H ; /* 

output ICWl 

*/ 

18 

2 

output (base+9) =0 ; /* 

output ICW2 

*/ 

19 

2 

output (base+9) =0 ; /* 

output mask 

word */ 


/* attach$device calls will initialize usarts and timers */ 

/* set up tables of port addresses for use by queue$io procs */ 

20 2 ret$data . t imer$cmd (0 ) ,ret$data . t imer$cmd ( 3 ) =36H ; 

21 2 ret$data . t imerSemd ( 1 ) =76H ; 

22 2 ret$data.timer$cmd (2)=0B6H; 

23 2 do i=0 to 3; 

24 3 ret$data.usart$cmd$port ( i) =base+2*i+l ; 

25 3 ret$data .usart$data$port ( i) =base+2*i ; 

26 3 ret$data .t imer$load$port { i) =base+i ; 

27 3 end; 

28 2 ret$data . t imer$ load$port ( 3 ) =base+4 ; 

29 2 ret$data ,t imer$cmd$port (0 ) , 

ret$data.timer$cmd$port (1) , 
retSdata.t imer$cmd Sport ( 2 ) =base+3 ; 

30 2 retSdata . t imerSemdSport ( 3 ) =base+7; 

31 2 return; 

32 2 end; 

33 1 end init$534$hw; 

MODULE INFORMATION: 

CODE AREA SIZE = 00E4H 228D 

CONSTANT AREA SIZE = 0000H 0D 

VARIABLE AREA SIZE = 0000H 0D 

MAXIMUM STACK SIZE = 0008H 8D 

77 LINES READ 
0 PROGRAM ERROR (S) 

END OF PL/M-86 COMPILATION 
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*_*_*_*_*_*_*_*_*_*_*_* NUCLNK.CSD — *_*_*_*_*_*_*_*_*_*_*_*_* 


f X ij> SJLJ r I X. X X X. X^Xi XAii-l MaXJ • 

:F0:LINK86 & 

:F1:NUC86.LIB(NENTRY) , & 

:F1; NUC86. LIB & 

TO ;F1; NUCLUS. LNK MAP PRINT (: FI : NUC LUS . MP 1 ) NAME (NUC LEUS ) 


*_*_*_*_*_*_*_*_*_*_*_* NUCLOC.CSD *-*_*_*_*_*_*-*-*_*_*_*_* 

THIS SUBMIT FILE LOCATES THE NUCLEUS IN MEMORY. 


:F0; LOC86 & 

; FI: NUCLUS. LNK TO :F1:NUCLUS MAP PRINT {: FI: NUCLUS .MP2) SC(3) & 
RESERVE (0 TO 7FFH) SEGS IZ E (STACK (0 ) ) & 

ORDER (CLASSES (CODE , DATA , STACK, MEMORY) ) & 

OBJECTCONTROLS (NOLINES , NOCOMMENTS , NOPUBLICS , NOSYMBOLS ) 


Nucleus Link and Locate Commands 
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; ios(date ,orig in) 

; Sample I/O System .csd file to link and locate an I/O System. 

; This file links an I/O System with the timer included. 

; This .csd file assumes the I/O System configuration module is 
; iocnfg.a86 (found on the release diskette). 

; The origin parameter sets the low address of the I/O System; 

; all the segments are contiguous in memory. 

asm86 : f 1 : iocnfg .a86 date(%0) 
link86 & 

:f l:ios.lib(ioinit) , & 

: f 1: iocnfg .obj , & 

:fl:ios.lib, & 

:f 1: rpifc .1 ib & 

to :fl:ios.lnk map pr int ( : f 1 ; ios .mpl) 
loc86 ;fl;ios.lnk to ;fl:ios map sc(3) print (: fl: ios. mp2) & 
oc ( nol i ,nopl ,nocm ,nosb) & 
order (classes(code,data,stack,memory) ) & 
addresses ( classes ( code (%1 )) ) & 
segsi ze ( stack ( 0 ) ) 


I/O System Link and Locate Commands 


; Submit file to generate located version of file transaction job 
i 

link86 & 

:f 1: f tini t .obj , & 

: f 1 : 1 isten .ob j , & 

:f 1; worker .obj , & 

:f lipointr .obj , & 

;f 1: rpifc .1 ib & 

to :f l;apexl.lnk map pr int ( : f l:apexl .mpl ) 

I 

loc86 ; f 1: apexl . Ink to :fl:apexl map sc(3) pr int ( : f 1 : apexl .mp2) & 
oc ( nol i ,nopl ,nocm ,nosb) & 
order ( classes ( code , data /Stack , memory) ) & 
addresses ( classes ( code ( %1 )) ) & 
segsi ze { stack ( 0 ) ) 

File Transaction Job; Link and Locate Commands 


; Submit file to generate located version of communications job 
/ 

link86 & 

: f 1 ; cmini t .obj , & 

:f l:comm.l ib, & 

;f lipointr .obj , & 

:f 1: rpifc .1 ib & 

to ;fl:comm.lnk map print (: f Irapexl .mpl) 
loc86 :fl:comm.lnk to ;fl;comm map sc(3) print (; f 1 : comm. mp2) & 
oc (nol i ,nopl ,nocm ,nosb) & 
order (classes (code, data /Stack /memory) ) & 
addresses (classes (code(%l) ) ) & 
segsi ze ( stack ( 0 ) ) 


Communications Job; Link and Locate Commands 
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077EH 

10E4H 

PUB 

INITDEVICETABLES 

077EH 

0FBCH PUB 

NAMEDDELETE 

077EH 

0EB3H 

PUB 

DECRUSECOUNT 


077EH 

0E51H PUB 

UNLINKCONN 

077EH 

0CA8H 

PUB 

NAMEDCHANGEACCES 

077EH 

0B5AH PUB 

ATTACHNAMEDFILE 

— ►077EH 

073EH 

PUB 

ATTACHDE VICETASK 

077EH 

0574H PUB 

ILLEGALFUNCT 

077EH 

003EH 

PUB 

RQAIOSINITTASK 

077EH 

0006H PUB 

COPYRIGHT 

SEGMENT MAP 







START 

STOP 

LENGTH ALIGN 

NAME 


CLASS 


077E0H 

1453EH 

CD5FH W 

CODE 


CODE 


14540H 

145FFH 

00C0H W 

REQ TABLE 

CODE 


14600H 

146DFH 

00E0H W 

I OS TABLE 

CODE 


— ►146E0H 

14745H 

0066H W 

DATA 


DATA 


14746H 

14746H 

0000H W 

STACK 


STACK 


14750H 

14750H 

0000H G 

??SEG 




— ►14750H 

14750H 

0000H W 

MEMORY 


MEMORY 



Locate Map for I/O System 

(The indicates entries for job macros and memory map) 


I 1475H 

079EH PUB 

SETUP544 


1475H 

06C5H PUB 

PACKETINPUT | 

1475H 

05B5H PUB 

INDEX 


— ►1475H 

0572H PUB 

COMMINITTASKENTRY 







-ESS 

SEGMENT MAP 






START 

STOP 

LENGTH ALIGN 

NAME 

CLASS 


14750H 

15BCDH 

147DH 

W 

CODE 

CODE 


— -►15BD0H 

170D2H 

1502H 

W 

DATA 

DATA 


170D2H 

1712EH 

004CH 

W 

STACK 

STACK 


17130H 

17130H 

0000H 

G 

??SEG 



— ►17130H 

17130H 

0000H 

W 

MEMORY 

MEMORY 



Locate Map for Communications Job 


17D6H 

03B5H PUB 

BEGINLISTENERTASKDATA1713H 

0153H PUB 

POINTERIZE 

— ►1713H 

0112H PUB 

INITTASKENTRY 1713H 

0401H PUB 

WORKERTASK 

SEGM ENT 

MAP 





START 

STOP 

LENGTH 

ALIGN NAME 

CLASS 


17130H 

17D59H 

0C29H 

W CODE 

CODE 


17D60H 

17E28H 

00C8H 

W DATA 

DATA 


17E30H 

17E 9AH 

006AH 

W STACK 

STACK 



Locate Map for File Transaction Job 
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Macro call: 


SYSTEM (system parameters) 



Number of calls required: 


exactly one 



CONFIGURATION FILE NAME 







FORMAT: 










suggested 



parameter 


type 

default 

value 

% SYSTEM 

(nucleus entry, 


base 


80:0 


rod size, 


word 

(0) 

JLQ 


min trans size. 


work 

(64) 




debugger. 


see note 

(A) 





1 


N 


default e h provided. 

see note 

(N) 





2 


N 


mode) 


word 


1 


NOTES: 

1. Valid entries forthedebugger parameter include; 

A Debugger available 

N No debugger available 

2. Valid entries for the default e h provided parameter include: 

Y Yes 

D Debugger 

N No 


%SYSTEM Macro Worksheet 
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Macro call; 

\ 

SAB (for system address blocks) 



Number of calls required; 

one or more 



CONFIGURATION FILE NAME; 

APEX1 








FORMAT: 

parameter 

type 

suggested 

default 

value 

%SAB 

(start_base, 

base 


0 


end base, 

base 


1900 


type) 

see note 
1 

U 

U 


NOTES: 

1 . The type parameter is reserved for future use. Enter 
the character U for this parameter. 

2. A SAB is declared between start baseiO and end base:F, inclusive. 


%SAB Macro Worksheet 
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Macro call; 

JOB (defines first-level jobs) 



Number of calls required: one for each first-level job 

CONFIGURATION FILE NAME: 

APEX1 








FORMAT: 







suggested 




parameter 

type 

default 

value 

%JOB 

(directory size, 

Word 

(0) 

0 


pool min, 

word 


OFFFF 


pool max. 

word 

(OFFFFH) 

OFFFF 


max objects. 

word 


FFFF 


max tasks. 

word 


FFFF 


max job priority. 

byte 


129 


exception_handler_entry. 

addr 

(0:0) 

0:0 


exception hand ler mode. 

byte 

(1) 

1 


job flags. 

word 

(0) 

_Q 


Init task priority. 

byte 


1713:112 


data segment_base. 

base 

(0) 

17D6 


stack pointer. 

addr 

(0:0) 

0:0 


stack size. 

word 

(512) 

512 


task flags) 

word 

(0) 

0 


NOTE: 

1 . addr is specified as base:offset 


% JOB Macro Worksheet 
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%sab(0, 1900,U) 

%job(0, 300h,0FFFh,0ff ffh,0fff fh, 0,0: 0,0,0, 12 8, 77e : 3e , 146e , 0 : 0 , 51 2 , 0 ) 

% job(0, 1FFH,0FFFH, 0FFFFH, 0FFFFH, 128, 0:0, 0, 0, 131, 1475 : 572, 15bd,0:0, 400, 0) 

% job(0, 300H, 0FFFFH,0FFFFH, 0FFFFH, 1 28, 0:0, 1,0, 130, 171 3:112, 17d6, 0:0, 400H,0) 
% system (80, 10, 64,N,N, 1) 


Configuration File Apex 1.CNF 


CTABLE.CSD — *_*_*_*_*_*_*_*_*_*_* 

; SUBMIT :Fx:CTABLE( fsys, fin, fout, config_file, date ) 
f 

j This submit file assembles the CTABLE module, where: 

; fsys = the system disk containing ASM86 

; fin = the source/input disk (FI is assumed) 

; fout = the object/listing/output disk 

; config_file = the path-name of the configuration file 

; date = the date 

copy CO : r i; coniiig .cnj- u 

:%0:asm86 : %1 : c table. a86 pr ( : %2:ctable.lst) oj ( : %2:ctable.obj) date(%4) & 
xref debug ep 


Submit File to Generate Configuration Table 


CLNKRJ.CSD — *_*-*_*_*_*_*_*_*_*_* 

t 

; SUBMIT :Fx:CLNKRJ( fsys, fin, fout ) 

/ 

; This submit file links the Root-Job, where: 

; fsys = the system disk containing LINK86 

; fin = the source/input disk 

; fout = the object/listing/output disk 

f 

:%0:link86 : %1 : c root . 1 ib ( root) ,& 

: %2 ; ctable .obj ,& 

: %1 : croot .1 ib & 

to :%2: rootjb.lnk map pr ( : %2 : roo t j b.mpl ) 


Submit File to Link the Root Job 
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•*_*_*_*_*_*_*_*_*_*_* CLOCRJ.CSD *_*_*_*_*—*_*_*_*—* 

; SUBMIT :Fx:CLOCRJ( f sys , fin, fout ) 

i 

; This submit file locates the Root-Job, where: 

; fsys = the system disk containing LOC86 

; fin = source/input disk 

; fout = object/listing/output disk 

; — NOTE: BE SURE TO REPLACE THE "?????" BELOW WITH THE APPROPRIATE 
; — ADDRESS THE ROOT-JOB IS TO BE LOCATED AT!! 

9 

:%0:loc86 : %2 : roo t j b . 1 nk to :%2:rootjb & 
map pr ( : %2: rootjb.mp2) sc(3) & 
name(ROOT_JOB) oc ( nocm ,nol i ,nopl ,nosb) & 
segsi ze ( stack ( 200h) ) & 

order (cl asses (data, stack, memory, code) ) & 
addresses(classes(data(12C00H) ) ) 


Submit File to Locate Root Job 
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REQUEST FOR READER'S COMMENTS 


The Microcomputer Division Technical Publications Department attempts to provide documents that meet the needs of all 
Intel product users. This form lets you participate directly in the documentation process. 

Please restrict your comments to the usability, accuracy, readability, organization, and completeness of this document. 

1. Please specify by page any errors you found in this manual. 


2. Does the document cover the information you expected or required? Please make suggestions for improvement. 


J. IS this the right type ot document tor your needs? Is it at the right level? What other types of documents are needed? 


4. Did you have any difficulty understanding descriptions or wording? Where? 


5. Please rate this document on a scale of 1 to 10 with 10 being the best rating. 
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Turkelek Electronics 
Apapurk Boulevard 169 
Ankara 
Tel; 189483 

UNITED KINGDOM 

Comway Microsystems Ltd. 
Market Street 
68-Bracknell, Berkshire 
Tel; (344)51654 
TELEX: 847201 

G.E.C. Semiconductors Ltd. 
East Lane 
North Wembley 
Middlesex HA9 7PP 
Tel: (01)904-9303/908-4111 
TELEX: 28817 
Jermyn Industries 
Vestry Estate 
Sevenoaks, Kent 
Tel; (0732)501.44 
TELEX; 95142 

Rapid Recall, Ltd. 

6 Soho Mills Ind. Park 
Wooburn Green 
Bucks, England 
Tel; (6285)24961 
TELEX: 849439 

Sintrom Electronics Ltd.’ 
Arkwright Road 2 
Reading, Berkshire RG2 OLS 
Tel: (0734)85464 
TELEX: 847395 

VENEZUELA 

Componentes y Circuitos 
Eiectronicos TTLCA C.A. 
Apartado 3223 
Caracas 101 
Tel; 718-100 

TELEX: 21795 TELETI PCS 
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INTERNATIONAL SALES AND MARKETING OFFICES 



INTEL« MARKETING OFFICES 


AUSTRALIA 

Intel Australia 

Suite 2, Level 15, North Point 
100 Miller Street 
North Sydney, NSW, 2060 
Tel: 450-847 
TELEX: AA 20097 

BELGIUM 

Intel Corporation S.A. 

Rue du Moulin a Papier 51 
Boite 1 

B-1160 Brussels 
Tel: (02)660 30 10 
TELEX: 24814 

DENMARK 

Intel Denmark A/S* 

Lyngbyvej 32 2nd Floor 
DK-2100 Copenhagen East 
Tel: (01) 18 20 00 
TELEX: 19567 

FINLAND 

Intel Scandinavia 
Sentnerikuja 3 
SF - 00400 Helsinki 40 
Tel: (0)558531 
TELEX: 123 332 

FRANCE 

Intel Corporation, S.A.R.L.* 

5 Place de la Balance 
Silic 223 

94528 Rungis Cedex 
Tel: (01)687 22 21 
TELEX: 270475 


GERMANY 

Intel Semiconductor GmbH* 
Seidlstrasse 27 
8000 Muenchen 2 
Tel: (089)53 891 
TELEX: 523 177 

Intel Semiconductor GmbH 
Mainzer Strasse 75 
6200 Wiesbaden 1 
Tel: (06121)700874 
TELEX: 04186183 

Intel Semiconductor GmbH 
Wernerstrasse 67 
P.O. Box 1460 
7012 Fellbach 
Tel: (0711)580082 
TELEX: 7254826 

Intel Semiconductor GmbH 
Hindenburgstrasse 28/29 
3000 Hannover 1 
Tel: (0511)852051 
TELEX: 923625 

HONG KONG 

Intel Trading Corporation 

99-105 Des Voeux Rd., Central 

18F, Unit B 

Hong Kong 

Tel: 5450-847 

TELEX: 63869 

ISRAEL 

Intel Semiconductor Ltd.* 

P.O. Box 2404 
Haifa 

Tel: 972/452 4261 
TELEX: 92246511 


ITALY 

Intel Corporation Italia, S.p.A. 
Corso Sempione 39 
1-20145 Milano 
Tel: 2/34.93287 
TELEX: 311271 

JAPAN 

Intel Japan K.K.* 

Flower Hill-Shinmachi East Bldg. 
1-23-9, Shinmachi, Setagaya-ku 
Tokyo 154 
Tel: (03)426-9261 
TELEX: 781-28426 

NETHERUNDS 

Intel Semiconductor B.V. 
Cometongebouw 
Westblaak 106 
3012 Km Rotterdam 
Tel: (10)149122 
TELEX: 22283 

NORWAY 

Intel Norway A/S 

P.O. Box 92 

Hvamveien 4 

N-2013 

Skjetten 

Tel: (2) 742 420 

TELEX: 18018 


SWEDEN 

Intel Sweden A.B.* 

Box 20092 
Alpvagen 17 
S-16120 Bromma 
Tel: (08)98 53 90 
TELEX: 12261 

SWITZERLAND 

Intel Semiconductor A.G. 
Forchstrasse 95 
CH 8032 Zurich 
Tel: 1-55 45 02 
TELEX: 557 89ichch 

UNITED KINGDOM 

Intel Corporation (U.K.) Ltd. 
Broadfield House 

4 Between Towns Road 
Cowley, Oxford 0X4 3NB 
Tel: (0865)77 14 31 
TELEX: 837203 

Intel Corporation (U.K.) Ltd.* 

5 Hospital Street 
Nantwich, Cheshire CW5 5RE 
Tel: (0270)62 65 60 
TELEX: 36620 

Intel Corporation (U.K.) Ltd. 
Dorcan House 
Eldine Drive 

Swindon, Wiltshire SN3 3TU 
Tel: (0793)26101 
TELEX: 444447 INT SWN 
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INTEL CORPORATION, 3065 Bowers Avenue, Santa Clara, California 95051 • (408) 734-8102 x598 
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